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Abstract 

Developers  of  applications  for  embedded  systems  need  full 
implementations  for  all  of  the  representation  clauses  and 
implementation-dependent  features  in  Chapter  13  of  the  Language 
Reference  Manual  (LRM)  if  they  are  to  be  successful  in 
developing  these  applications  entirely  in  Ada.  Because 
implementations  of  Ada’s  representation  clauses  and 
implementation-dependent  features  vary  from  compiler  to 
compiler,  these  features  must  be  validated  and  evaluated  before 
they  are  used  _  n  applications  that  have  such  high  reliability 
requirements.  This  thesis  describes  an  approach  used  to 
develop  validation  tests  and  performance  evaluation  tests,  or 
benchmarks ,  for  Ada’s  address  clauses  and  interrupts  features 
and  reports  the  results  of  the  validation  tests  and 
benchmarks . 

The  validation  tests  were  compiled  with  three  validated 
Ada  compilers,  two  of  which  were  targeted  to  the  MIL-STD- 1 750A 
processor.  The  benchmarks  developed  in  this  research  measure 
interrupt  delay  time  for  interrupts  associated  with  a  task 
entry  by  an  address  clause.  These  benchmarks  were  compiled 
with  a  validated  Ada  compiler  targeted  to  the  MIL-STD- 1750A  and 
run  on  a  Sperry  1631  MI L-STD- 1750A  processor. 


VALIDATING  AND  EVALUATING  ADA’S  REPRESENTATION  CLAUSES  AND 
IMPLEMENTATION-DEPENDENT  FEATURES  ON  MIL-STD- 1750A  ARCHITECTURE 


I .  I ntroduc t i on 

In  the  mid-1970s,  because  of  rising  software  costs  and 
increasingly  unreliable  software,  the  Department  of  Defense 
(DoD)  started  the  development  of  a  new  high-order  computer 
programming  language,  now  known  as  Ada.  In  an  effort  to  direct 
the  development  and  use  of  the  language,  the  DoD  established 
the  Ada  Joint  Program  Office  (AJPO)  to  manage  all  Ada-related 
activities  (Booch,  1987:22).  One  of  the  most  important 
activities  of  the  AJPO  is  validating  Ada  compilers  (programs 
that  translate  Ada  source  code  into  machine  instructions), 
because,  by  DoD  directive,  only  validated  Ada  compilers  can  be 
used  to  develop  Ada  software  for  the  DoD  (AJPO,  1987) .  To  be 
validated,  a  compiler  must  pass  a  series  of  tests,  known  as  the 
Ada  Compiler  Validation  Capability  (ACVC) ,  that  demonstrates 
the  compiler's  adherence  to  ANS I /MIL-STD- 1 8 1 5A ,  Ada  Programming 
Language  Reference  Manual  (LRM)  (DoD,  1983). 

Even  if  a  compiler  is  validated,  it  still  may  not  meet  the 
execution  requirements  of  embedded  systems.  The  validation 
process  does  not  provide  an  evaluation  of  a  compiler’s 
efficiency  or  performance;  it  will  only  determine  whether  or 
not  a  compiler  complies  with  the  Ada  LRM  (AJPO,  1987:1). 


Problem  Statement 


Before  using  an  Ada  representat ion  clause  or 
implementation-dependent  feature  described  in  Chapter  13*  of 
the  LRM,  researchers  and  developers  of  embedded  applications  in 
Ada  must  determine  two  things: 

1)  Does  the  Chapter  13  feature’s  implementation 
conform  to  the  description  in  the  Ada  Programming 
Language  Reference  Manual  (LRM)? 

2)  If  so,  how  efficient  is  the  implementation 
(compared  to  other  compilers’  Implementations  of  the 
same  f eatur e ) ? 

Ada  validation  and  performance  evaluation  tests  did  not  exist 
to  answer  these  questions  when  this  thesis  project  began. 


Background 

One  of  the  driving  forces  behind  the  development  of  Ada 
was  a  Department  of  Defense  (DoD)  need  to  develop  a  high  order 
language  that  met  the  requirements  of  embedded  systems  (Booch, 
1987:14) .  Booch  defines  an  embedded  system  as  a  "computer 
system  .  that  forms  a  part  of  a  larger  system  whose  purpose 

is  not  primarily  computational,  such  as  a  weapons  system  or  a 
process  controller"  (Booch,  1987:15-16).  Because  of  physical 
limitations  on  embedded  systems’  memory  (often  64  to  128 
kilobytes)  and  embedded  systems’  real-time  processing 
requirements,  applications  for  embedded  systems  often  were  (and 


still  are)  written  in  JOVIAL  (DoD,  1984),  assembly 


For  the  sake  of  brevity  I  will  refer  to  the  representation 
clauses  and  implementation-dependent  features  of  Ada  as 
"Chapter  13  features'  in  the  course  of  this  thesis. 


language,  or  some  combination  of  the  two  (King,  1987) ,  because 
of  the  compactness  and  execution  time  efficiency  of 
applications  developed  in  these  languages.  However,  although 
JOVIAL  and  assembly  language  routines  can  address  memory 
directly  and  efficiently  perform  other  low-level  operations, 
applications  written  in  these  languages  are  difficult  to 
maintain.  Since  the  DoD  has  directed  that  Ada  be  used  to 
develop  all  new  embedded  applications  (DoD,  1987)  ,  the  Chapter 
13  features  will  have  to  perform  these  low-level  operations  as 
efficiently  as  JOVIAL  and  assembly  language  if  Ada  is  to 
eventually  replace  those  languages. 

Ada's  representation  clauses  (1)  describe  how  data  types 
(such  as  integer,  real,  array,  and  record  types)  are  to  be 
mapped  onto  the  underlying  machine,  thus  allowing  for  a  more 
efficient  representation  than  would  be  possible  with  the 
default  definitions  for  these  types;  and  (2)  allow  the  direct 
specification  of  memory  addresses  for  objects  and  programs 
(DoD,  1983:Ch  13,  1) .  For  example,  assume  an  embedded  system 

whose  normal  representation  for  integer  data  types  is  a  16-bit 
word.  If  the  developer  knows  that  all  of  the  integer  values  in 
an  application  can  be  stored  in  eight  bits,  he  can  define  the 
representation  for  integers  to  be  eight  bits,  effectively 
doubling  the  number  of  integers  he  can  store. 

The  implementation-dependent  features  of  Ada  provide  (1) 
for  specifying  underlying  system  characteristics;  (2)  for 
freeing  unused  memory  that  has  been  dynamically  allocated;  and 
(3)  for  performing  data  conversions  that  Ada  normally  does  not 

3 


,V.V.>VVY‘ 


»'*  .s  A'A  » 


allow  because  of  its  strong  typing  (Booch,  1987:332).  Without 
these  features,  Ada  can  not  perform  the  same  functions  as 
assembly  language  routines;  therefore,  the  features  in  Chapter 
13  are  vital  to  any  embedded  applications  written  entirely  in 
Ada  . 

Only  one  organization,  SofTech  Inc. ,  is  now  developing 
tests  (Wilson,  1987a)  for  the  ACVC  for  the  existence  and 
correct  implementation  of  Chapter  13.  While  additional  tests 
will  be  added  to  the  ACVC  in  subsequent  releases,  version  1.9 
of  the  ACVC,  released  1  June  1987,  included  only  four  Chapter 
13  tests,  and  these  test  but  one  feature  (Wilson,  1987a) . 

There  are  at  least  two  major  efforts  underway  for 
evaluating  the  performance  of  Ada  compilers.  The  Boeing 
Military  Airplane  Company  is  currently  under  contract  to  the 
Ada  Evaluation  and  Validation  Team  of  the  AJPO  to  develop  the 
Ada  Compiler  Evaluation  Capability  (ACEC) ,  a  test  suite  that 
will  include  performance  tests  for  (among  others)  Chapter  13 
features  of  the  language  (BMAC,1987).  The  second  effort  is 
that  of  the  Performance  Issues  Working  Group  (PIWG)  of  the 
Association  for  Computing  Machinery  (ACM)  Special  Interest 
Group  on  Ada  (SIGAda) .  Among  other  activities,  the  PIWG 
collects  compiler  benchmarks  from  its  members  and  places  them 
in  the  public  domain;  performance  evaluation  benchmarks  for 
Chapter  13  features  are  among  these  (Squire,  1987). 
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Scope 

The  goals  of  this  thesis  project,  then,  were  (1)  to  expand 
the  existing  compiler  validation  and  evaluation  methods  or 
develop  new  methods,  as  necessary,  for  validating  and 
evaluating  Chapter  13  features  of  Ada  and  (2)  to  certify  these 
methods  by  writing  needed  validation  and  evaluation  tests  and 
applying  them  to  compilers  targeted  to  embedded  computers.  All 
compilers  run  on  one  computer  (the  ‘host  computer’)  and  produce 
machine  instructions  for  another  computer  (the  ‘target 
computer')  that  may  or  may  not  be  the  same  as  the  host.  In 
this  thesis,  I  studied  Ada  compilers  targeted  to  MIL-STD- 1750A 
computers,  the  standard  airborne  (embedded)  computers  for  the 
US.  Air  Force  (DoD,  1982:1). 

I  did  not  develop  tests  for  all  of  the  features  in  Chapter 
13;  instead,  I  concentrated  on  the  features  most  important  to 
the  development  of  embedded  systems  applications.  My  ordering 
of  importance  was  based  on  the  assumption  that  embedded  systems 
developers  would  be  using  a  mix  of  Ada,  JOVIAL,  and  assembly 
language  in  the  near  future  because  of  the  current  lack  of  Ado 
compilers  with  full  Chapter  13  implementations  targeted  to  the 
MIL-STD- 1750A  computer. 


Research  Approach 

Chapter  13  Feature  Identification.  I  identified  the  most 
important  Chapter  13  features  for  embedded  systems  by  a  review 
of  current  literature  and  by  discussions  with  embedded  systems 
developers  in  the  Aeronautical  Systems  Division  Systems 
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Engineering  Avionics  Facility  (ASD/ENASF) ,  embedded  systems 
developers  in  the  Air  Force  Wright  Aeronautical  Laboratories 
System  Evaluation  Branch  (AFWAL/AAAF)  and  Information 
Processing  Technology  Branch  (AFWAL/AAAT) ,  and  other  embedded 
systems  developers  in  the  Air  Force  and  industry. 

Write  and  Run  Prototype  Tests.  I  wrote  tests  for  the 
validity  and  efficiency  of  a  Chapter  13  feature  that  was 
implemented  by  at  least  two  Ada  compilers  targeted  to  the  host 
computer.  The  process  of  writing  and  running  these  tests 
helped  to  refine  the  requirements  for  the  remaining  tests,  to 
identify  potential  problem  areas,  and  to  learn  the  size  and 
difficulty  of  the  thesis  problem. 

Identify/Obtain  Compilers.  Based  on  the  Chapter  13 
features  identified  for  study,  I  chose  the  candidate  compilers 
that  were  used  in  my  thesis  project.  I  included  compilers  that 
were  hosted  on  and  targeted  to  the  same  computer,  as  well  as 
compilers  that  were  targeted  to  a  MI L-STD- 1 750A  computer  to 
provide  a  broad  range  of  compi ler/host  combinations.  Compilers 
targeted  to  the  host  machine  typically  included  better  tools 
(such  as  debuggers),  which  were  helpful  in  developing  the  test 
sof  tware . 

Write  and  Run  Tests  on  Host-Targeted  Compilers.  Using  the 
methods  developed  in  writing  the  prototype  tests,  I  wrote  the 
tests  for  the  Chapter  13  features  identified  earlier  and  then 
ran  the  tests  on  the  compilers  that  were  targeted  to  the  host 
computer  to  take  advantage  of  diagnostic  tools  discussed 
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above.  Based  on  this  preliminary  testing  and  analysis,  I  had 
to  re-write  and  re-run  some  of  these  tests. 


Run  Tests  on  1750A-Tar geted  Compilers.  After  establishing 
the  validity  of  the  tests  on  the  host- targeted  compilers,  I 
applied  them  to  the  Ada  compilers  that  are  targeted  to  the 
MIL-STD- 1750A  computers. 

Certify  Tests  and  Analyze  Results.  Finally,  I  certified 
that  the  tests  developed  in  this  thesis  answered  the  questions 
stated  in  the  thesis  problem  and  analyzed  the  results  of  the 
tests.  The  results  of  the  validation  tests  were  discrete;  a 
compiler  either  passed  or  failed  the  applicable  tests.  The 
results  of  the  performance  evaluation  teat  were  continuous 
execution  times,  so  I  was  able  to  support  the  hypothesis  that 
the  mean  test  execution  times  for  various  benchmarks  differed, 
and  to  explain  the  causes  for  those  differences.  Using  these 
results,  I  wrote  conclusions  and  recommendations. 

Materials  and  Equipment 

The  compilers  needed  for  this  thesis,  including  compilers 
that  are  targeted  to  the  MIL-STD- 1750A  computer,  were  generally 
available  at  AFIT  and  through  organizations  at  Wright-Patterson 
AFB .  AFWAL/AAAT  and  the  thesis  sponsor,  ASD/ENASF,  provided 
access  to  MIL-STD- 1750A  computers,  Ada  compilers  targeted  to 
those  computers,  and  the  assistance  of  personnel  knowledgeable 
in  the  operation  of  this  hardware  and  software.  Finally,  I  was 
given  access  to  the  ARPANET  to  obtain  public  domain  test 
software  and  information  on  the  state  of  current  Ada  research. 
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Maximum  Expected  Gain 


I  expected  this  thesis  to  break  new  ground  in  the  area  of 


testing  Ada’s  Chapter  13  features.  Many  are  hesitant  to  use 


Ada  because  it  is  an  immature  language,  and  few  want  to  take  a 


risk  on  unproven  features  in  the  language  (Myers,  1987:71) . 


This  thesis  should  remove  some  of  the  uncertainty  surrounding 


Chapter  13  features  by  providing  sound  tests  for  the  validity 


and  performance  of  those  features.  This  work  is  immediately 


useful  to  developers  of  embedded  applications  in  Ada,  as  well 


as  to  those  who  are  developing  Ada  compilers  that  will 


implement  these  features,  because  it  provides  a  method  for 


testing  the  validity  and  efficiency  of  these  features  before 


they  must  be  used.  Finally,  the  AVF  expressed  an  interest  in 


the  results  of  this  thesis  in  developing  new  tests  for  the  ACVC 


test  suite  (Chitwood,  1987),  and  some  of  the  validation  tests 


written  in  this  thesis  were  incorporated  in  version  1.10  of  the 


Ada  Compiler  Validation  Capability  test  suite  (Brashear, 


1987b) 


Sequence  of  Presentation 


The  theory  and  method  of  compiler  validation  and 


performance  evaluation  are  summarized  in  Chapter  2.  This 


chapter  also  identifies  some  of  the  deficiencies  of  previous 


methods  in  these  two  fields. 


The  design  of  the  validation  and  evaluation  tests 


developed  in  this  thesis  is  presented  in  Chapter  3.  This 


chapter  describes  the  test  requirements,  justifies  the 
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requirements,  and  gives  a  general  approach  to  test  design  that 
fulfills  these  requirements. 


Chapter  4  describes  the  detailed  design  of  the  tests. 
Chapter  5  details  how  the  tests  were  certified  and  reports 
the  results  of  the  Chapter  13  feature  tests. 


1 1 .  Literature  Surve 


The  development  of  tests  for  correct  and  efficient 
implementations  of  features  of  the  Ada  programming  language  is 
guided  by  two  of  the  most  important  disciplines  of  compiler 
analvsis:  validation  and  performance  evaluation.  This  chapter 

will  review  current  theory  and  method  in  these  two  areas  and 


relate  them  to  the  problem  of  testing  representation  clauses 
and  implementation-dependent  features  of  Ada. 

Compiler  Validation 

One  of  the  major  design  requirements  for  Ada  in  the  early 
stages  of  its  development  was  that  the  software  developed  with 
Ada  and  the  programmers  trained  with  Ada  be  portable 
(Ploedereder ,  1986:  Ch  7,  1).  All  too  often,  pre-Ada  software 

had  to  be  extensively  rewritten  when  moved  to  another  computer 
system,  and  programmers  had  to  be  trained  in  new  programming 
languages  whenever  they  moved.  Although  standards  exist  for 
languages  such  as  Pascal,  JOVIAL,  and  COBOL,  past  experience 
had  shown  that  software  was  often  developed  using  a 
non-standard  or  extended-standard  compiler,  making  it  very 
costly  to  move  an  application  to  a  new  computer  because  of  the 
differences  between  the  old  and  new  compilers.  This  is  one  of 
the  primary  reasons  that  no  subset,  extended,  or  non-standard 
Ada  compilers  are  allowed  (Ploedereder,  1986:  Ch  7,  1). 

The  Ada  Compiler  Validation  Capability  (ACVC) 

Implementers ’  Guide  'describes  implementation  implications  of 
the  LRM  and  conditions  to  be  checked  by  validation  tests' 
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(Goodenough,  1986:Ch  1,  1).  This  guide  provides  semantic 
ramifications,  legality  rules,  and  AJPO-approved 
interpretations  of  Ada  constructs  as  well  as  test  objectives 
and  design  guidelines  for  all  validation  tests.  Although  test 
objectives  and  design  guidelines  have  been  written,  only  a 
subset  of  these  have  been  turned  into  working  validation  test 
programs  (Wilson,  1987a). 

The  3100  tests  in  version  1.9  of  the  A CVC  fall  into  the 
following  classes:  (1)  Class  A  tests  ensure  the  minimum 
allowable  set  of  the  language  is  implemented;  (2)  Class  B  tests 
determine  whether  a  compiler  can  detect  illegal  uses  of  the 
language;  (3)  Class  C  tests  are  run-time  tests  that  should 
compile  and  execute  successfully;  (4)  Class  D  tests  determine 
the  capacity  of  the  implementation  of  the  language  constructs, 
such  as  determining  how  many  levels  of  loop  nesting  an 
implementation  will  support;  (5)  Class  E  tests  determine 
whether  implementation-dependent  attributes  of  language 
features  have  been  provided  for;  and  (6)  Class  L  tests 
determine  the  compiler’s  ability  to  detect  link-time  errors 
(Wilson,  1987b).  A  compiler,  however,  does  not  necessarily  have 
to  implement  all  of  the  features  in  Chapter  13  to  pass  these 
tests.  For  example,  the  Ada  LRM  states:  'An  implementation 

may  limit  its  acceptance  of  representation  clauses  to  those 
that  can  be  handled  simply  by  the  underlying  hardware'  (DoD, 
1983:  Ch  13,  2) .  Because  certain  Chapter  13  features  are 
considered  optional  and  because  Initial  A CVC  emphasis  was 
placed  on  testing  the  mandatory  features  of  the  language,  early 


versions  of  the  ACVC  did  not  include  tests  for  features  in 
Chapter  13  of  the  LRM,  even  though  some  such  features,  such  as 
package  SYSTEM  (which  defines  characteristics  of  the  target 
computer)  must  be  provided  by  an  implementation  (DoD,  1983:Ch 
13 ,  9)  . 

Also,  because  Ada  compilers  are  currently  validated  with  a 
test  suite  that  tests  only  a  subset  of  the  language  (Wilson, 
1987a),  a  validated  compiler  could  have  an  illegal 
implementation  of  some  untested  feature.  For  example,  a 
compiler  that  has  an  incorrect  implementation  for  address 
clauses  (one  of  the  Chapter  13  features)  could  be  validated 
with  the  current  (version  1.9)  or  previous  versions  of  the  ACVC 
test  suite  because  these  versions  did  not  contain  tests  for 
address  clauses. 

Finally,  because  the  ACVC  test  suite  makes  no  inferences 
about  the  relative  efficiency  of  one  compiler  versus  another 
(Wilson,  1987a)  ,  compiler  validation  cannot  be  used  to 
determine  the  suitability  of  a  compiler  for  a  particular 
application  (AJPO,  1987:1).  The  Ada  compiler  validation 
process  has  discrete  results  --  either  a  compiler  passes  all 
applicable  tests  and  is  validated  as  conforming  to  the 
standard,  or  it  fails  at  least  one  applicable  test  and  is  not 
val ldated . 

Compiler  Performance  Evaluation 

Compiler  performance  evaluation,  or  benchmarking,  is  an 


outgrowth  of  the  computer  benchmarking  field.  Computer 


benchmarking  techniques  developed  in  the  early  1970s,  as 


potential  purchasers  of  large  computer  systems  searched  for  a 

tool  that  could  provide  an  objective  measure  of  a  computer’s 

processing  power  (Benwell,  1975:  vii-viii).  Performance 

evaluation  programs,  or  benchmarks ,  were  developed  to  measure  a 

computer’s  processing  power  by  measuring  the  computer’s 

execution  time  for  a  representative  set  of  computer 

instructions.  The  basic  approach  in  benchmarking  computers  is 

to  hold  all  other  factors  (such  as  computer  programming 

language  use,  number  of  iterations,  etc.)  constant  in  a 

benchmark  execution,  varying  only  the  the  computer  being 

benchmarked;  thus  any  difference  in  test  results  may  be 

attributed  to  differences  in  the  computers’  execution  speeds. 

This  same  method  may  be  applied  to  benchmarking  compilers. 

There  are  three  approaches  that  have  been  used  to  evaluate 

the  efficiency  of  Ada  and  other  high  order  languages  (HOLs) 

using  the  metric  of  execution  speed: 

writing  (1)  a  set  of  small  well-established  numerical 
benchmarks,  (2)  a  sample  of  representative  programs 
from  the  application  domain,  and  (3)  a  synthetic 
benchmark  in  Ada  and  other  high  order  languages, 
viz. ,  FORTRAN  and  Pascal,  and  comparing  the  resulting 
compilation  and  execution  times  (Bassman  and  others, 

1985 : 151) . 

Sumer ical  benchmarks  were  originally  developed  to  benchmark 
scientific  computers  whose  primary  functions  were  floating 
point  mathematical  operations.  Because  such  benchmarks  do  not 
typically  use  the  more  modern  constructs,  such  as  tasking  and 
access  types,  of  a  language  such  as  Ada,  they  cannot  accurately 
evaluate  these  features  (Weicker,  1984:1013).  Application 
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domain  benchmarks  are  application  programs  that  have  been 
modified  to  include  code  for  reporting  performance  of  the 


program  (Craine,  1986:13).  Because  compilers  targeted  to 
MIL-STD- 1750A  computers  have  so  far  implemented  few  of  the 
Chapter  13  features,  applications  using  these  features  are 
generally  unavailable.  A  synthetic  benchmark  includes  a 
balance  of  instructions  that  is  typical  of  the  general  use  of  a 
computer  language,  based  on  a  statistical  analysis  of  a  large 
number  of  applications  written  in  that  language  (Bassman  and 
others ,  1985: 151) . 

While  these  three  approaches  provide  comparative 


information  for  general-purpose  (non-embedded)  computers,  they 
do  not  give  quantitative  results  that  can  be  used  by  the 
compiler  implementers  and  users  concerned  with  the  effects  of 


specific  language  features,  because  the  results  are  distorted 
by  the  effects  of  other  language  constructs  used  in  the 
benchmarks  (Bassman  and  others,  1985:151). 

To  benchmark  the  performance  of  an  Ada  compiler  and  that 
of  another  HOL  such  as  Pascal  (or  another  vendor’s  version  of 
Ada) ,  another  approach  that  may  be  adapted  to  embedded  computer 
systems  includes: 

(1)  Programming  test  cases  for  fundamental  language 
features  in  Ada,  the  HOL,  and  assembly  language;  (2) 
Writing  test  cases  for  code  improvement  in  Ada  and 


the  HOL;  and  (3)  Programming  representative 
applications  in  Ada,  the  HOL,  and  assembly  language 
(Bassman  and  others,  1985:153). 

This  approach  is  suitable  for  benchmarking  compilers  targeted 
to  embedded  processors  because  it  provides  ‘detailed  knowledge 


14 


of  the  performance  of  individual  features  (Clapp  and  others, 
1986:767;  Bassman  and  others,  1985:155).  In  this  approach,  the 
benchmarks  are  designed  to  measure  the  execution  time  of 
specific  language  features  by  isolating  the  feature  in  a  test 
loop  of  the  benchmark  and  determining  the  difference  in 
execution  time  between  the  teat  loop  and  a  control  loop  in 
which  the  feature  is  not  used  (Clapp  and  others,  1986:767) . 

This  approach  will  be  referred  to  as  the  ’dual-loop  approach’ 
in  the  remainder  of  this  thesis. 

Because  of  the  limited  memory  available  to  and  real-time 
processing  requirements  for  embedded  applications,  two  of  the 
primary  requirements  for  benchmarks  for  Chapter  13  features  in 
embedded  applications  are  that  the  benchmark  measure  the 
feature's  memory  use  and  execution  speed  (Phillips  and 
Stevenson,  1984:4.100).  With  respect  to  memory  requirements, 
the  MIL-STD- 1750A  computer  with  the  extended  memory  option  now 
allows  an  application  to  address  up  to  one  megaword  of  memory, 
although  only  64K  words  each  of  data  and  instructions  may  be 
accessed  without  changing  page  registers  (Bunce,  1987).  As 
long  as  program  units  (such  as  tasks)  can  be  designed  so  that 
they  stay  within  a  64K  boundary  accessible  within  the  logical 
address  space,  the  application  does  not  suffer  from  excessive 
page  swapping  (Bunce,  1987)  .  New  embedded  applications  being 
developed  for  MI L-STD- 1 750A  will  most  likely  use  the  extended 
memory  option,  lessening  the  size  restrictions  on  those 
applications  (Lyons,  1987).  One  researcher  further  found  that 
the  arguments  against  using  Ada  for  applications  targeted  to 


the  MIL-STD- 1750A  computer  because  of  insufficient  memory  were 
based  on  worst-case  scenarios  instead  of  the  class  of 
applications  more  likely  to  be  found  on  embedded  systems 
(Roark,  1987b) .  In  fact,  embedded  real-time  applications 
researchers  and  developers  interviewed  in  this  research  were 
able  to  work  around  memory  limitations  or  found  that  their 
applications  were  not  limited  by  the  larger  memory  available 
with  the  extended  memory  MIL-STD- 1750A  (Clements,  1987;  Roark 
1987b) .  Nevertheless,  embedded  systems  benchmarks  should  still 
address  memory  usage  as  a  concern. 

With  respect  to  time  requirements,  although  research  is 
currently  being  conducted  to  develop  faster  MIL-STD- 1 750A 
computers  using  Very  High  Speed  Integrated  Circuit  (VHSIC) 
technology,  this  technology  may  not  be  available  in  time  to 
solve  the  more  pressing  timing  restrictions  currently  placed  on 
embedded  applications  (Pitarys,  1987).  Furthermore,  history 
indicates  that  time  efficiency  will  remain  a  concern  even  if 
much  faster  processors  are  found. 

Currently  there  are  two  major  sets  of  performance 
evaluation  software  available  in  the  public  domain:  the  SIGAda 

PIWG  benchmarks  and  the  Prototype  Ada  Compiler  Evaluation 
Capability  (ACEC) .  The  SIGAda  benchmarks  are  a  collection  of 
benchmarks  that  use  the  dual-loop  approach  to  measure  the 
execution  time  associated  with  such  constructs  as  task  creation 
and  elaboration,  exception  handling,  package  TEXT_IO,  loops, 
procedure  calls,  various  task  design  styles,  and  packed  boolean 
arrays  (PIWG,  1987) .  Except  for  the  benchmarks  that  measure 


the  effects  of  packing  boolean  arrays,  none  of  these  benchmarks 
measures  any  Chapter  13  features. 


The  prototype  ACEC  benchmarks  are  a  collection  of 
benchmarks  from  the  public  domain,  organized  for  the  Evaluation 
and  Validation  team  of  the  AJPO  by  the  Institute  for  Defense 
Analyses.  These  include  numerical  and  synthetic  benchmarks 
that  measure  the  execution  time  associated  with  tasking, 
procedure  calls,  loops,  case  statements,  recursive  calls,  and 
global  variable  access ,  among  others.  The  prototype  ACEC  does 
include  benchmarks  for  the  use  of  Chapter  13  features, 
including  measurements  for  unchecked  storage  deallocation  and 
mathematical  operations  on  objects  declared  with  a  length 
clause  (Witt,  1985:90-93). 

Other  sets  of  benchmarks  available  are  those  collected  on 
the  Ada  Software  Repository  (Conn,  1987:130)  which  include 
numerical  and  synthetic  benchmarks  from  the  1985  Los  Angeles 
ACM  AdaTEC  conference;  other  numerical  benchmarks  such  as 
Whetstone,  Dhrystone,  and  the  Sieve  of  Eras tothenes ;  synthetic 
benchmarks  to  measure  tasking  overhead;  and  finally,  a  copy  of 
the  ACM  SIGAda  PIWG  benchmarks.  These  collections  do  not 
contain  any  new  benchmarks  for  Chapter  13  features  beyond  those 
described  previously  in  this  chapter. 


17 


III.  System  Design  of  Chapter  13  Feature  Teste 


This  chapter  identifies  the  Chapter  13  features  chosen  for 
evaluation  and  describes  why  they  are  more  important  to 
embedded  applications  than  other  features.  The  requirements 
and  justification  are  also  presented  for  the  design  of  a  system 
of  tests  and  procedures  to  validate  and  evaluate  Chapter  13 
features . 

Identification  of  Chapter  13  Features  for  Testing 

Recall  from  Chapter  1  that  the  purpose  of  this  research 
was  to  expand  the  current  validation  and  performance  evaluation 
techniques  to  develop  tests  to  validate  and  evaluate  the 
features  of  Chapter  13  most  important  to  embedded 
app 1 i cat  1 ons .  This  section  describes  the  Chapter  13  features 
that  were  chosen  and  explains  why  they  were  chosen. 

Because  there  are  currently  very  few  Ada  compilers  with 
full  Chapter  13  implementations  available,  most  of  the  research 
to  identify  the  Chapter  13  features  important  to  embedded 
applications  developers  was  conducted  through  interviews  with 
those  developers.  Some  embedded  applications  developers 
interviewed  stated  flatly  that  they  needed  most  or  all  of  the 
Chapter  13  features  for  their  applications  (Roark,  1987;  Shaw, 
1987;  Lyons,  1987) .  Others  were  able  to  prioritize  the  need 
for  implementation  of  certain  features  based  on  their  knowledge 
that  they  currently  used  (or  would  soon  use)  the  feature  in  an 
application,  or  conversely,  that  they  would  not  use  a  feature 
(because  they  had  no  need  for  it,  the  feature  was  too  risky  to 
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use,  or  the  capability  could  be  provided  in  other  ways)  (King, 
1987;  Bennett,  1987;  Seward,  1987).  The  lack  of  production- 
quality  compilers  targeted  to  MIL-STD- 1750A  computers  still 
forces  developers  of  these  applications  to  use  a  mixture  of 
Ada,  assembly  language,  and  JOVIAL  (Bennett,  1987). 

In  these  discussions  with  embedded  applications  developers 
and  compiler  designers  for  those  applications,  then,  the 
features  that  were  identified  as  most  important  were  Address 
Clauses  and  Interrupts,  Record  Representation  Clauses,  Length 
Clauses,  and  Interface  to  Other  Languages. 

Address  Clause  and  Interrupts.  Ada’s  address  clauses 
allow  a  developer  to  specify  the  memory  location  (or  address) 
at  which  a  variable  is  to  be  stored  or  at  which  a  subprogram  or 
package  is  to  begin.  They  may  also  be  used  to  link  an 
interrupt  to  an  Ada  task  that  will  handle  the  interrupt  (DoD, 
1983:Ch  13,  5) .  These  features  are  vital  to  embedded 
applications,  especially  those  that  seek  to  minimize  the  number 
of  assembly  language  routines  included  to  perform  low-level 
operations.  It  is  the  nature  of  embedded  applications  that 
certain  operations,  such  as  reading  data  from  pre-determined 
Input/Output  (I/O)  ports,  must  be  tailored  to  the  configuration 
of  the  hardware.  Because  decisions  regarding  the  physical 
location  of  registers  and  I/O  ports  on  the  underlying  hardware 
are  made  long  before  software  is  developed,  software  must  adapt 
to  the  hardware.  For  example,  the  device  that  determines  the 
airspeed  of  an  aircraft  may  be  physically  connected  to  an  I/O 
port  at  memory  address  2000  of  an  embedded  computer,  so  data 


from  the  device  must  be  read  from  that  location.  By  specifying 
that  the  variable  that  will  contain  the  information  be  loaded 
at  that  address,  the  data  from  the  device  can  be  read  from  the 
variable.  If  this  feature  were  not  provided,  an  application 
would  have  to  make  a  call  to  an  assembly  language  or  JOVIAL 
routine  to  retrieve  the  data  from  address  2000. 

Another  feature  that  is  closely  related  to  address  clauses 
is  Ada’s  interrupt  handling  feature.  An  interrupt  is  an  event 
during  the  execution  of  a  program  that  indicates  an  error  in 
the  hardware  or  software  has  occurred  or  that  signals  that  some 
device  attached  to  the  computer  needs  service.  The  interrupt 
notifies  the  Central  Processing  Unit  (CPU)  to  suspend  its 
current  operation  and  take  action  on,  or  handle,  the  event  that 
caused  the  interrupt.  For  example,  an  I/O  interrupt  may  signal 
the  CPU  that  data  is  ready  to  be  read  from  an  I/O  port.  The 
CPU,  in  turn,  handles  the  interrupt  by  moving  the  data  from  the 
I/O  port  to  main  memory.  Many  embedded  applications,  such  as 
avionics,  are  typically  interrupt  driven  (DoD,  1982),  i.e., 

interrupts  (rather  than  polling  schemes)  are  used  to  indicate 
when  I/O  or  hardware  devices  need  service  (Bennett,  1987). 

Since  Ada  was  designed  for  embedded  systems  (Booch,  1987) , 
providing  a  capability  to  handle  interrupts  is  crucial.  Ada’s 
interrupts  feature  allows  applications  to  handle  asynchronous 
interrupts  by  associating  a  task  entry  with  a  memory  location 
that  contains  the  interrupt  vector  or  the  number  of  the 
interrupt  itself.  When  the  interrupt  occurs,  the  associated 


task  entry  is  called  and  the  interrupt  is  handled  by  the  body 
o f  the  task . 

Record  Representation  Clauses.  Record  representation 
clauses  allow  the  embedded  applications  developer  to  declare 
and  use  variables  that  represent  low-level  values  normally  not 
accessible  with  other  high-order  languages.  A  common  example 
of  this  would  be  to  use  the  record  representation  clause  to 
declare  a  record  representation  for  a  computer’s  program  status 
word  (PSW)  (DoD,  1983:Ch  13,  6;  DoD,  1982,  11),  in  which 
information  about  the  state  of  the  CPU  and  other  devices  is 
stored  in  specific  bit  positions.  The  capability  to  access  the 
PSW  can  be  vital  to  an  application  because  its  values  often 
determine  the  sequence  of  future  operations  in  the 
application.  Without  record  representation  clauses,  an  Ada 
application  would  have  to  incorporate  a  number  of  assembly 
language  routines  to  retrieve  and  decode  information  stored  in 
registers  such  as  the  PSW  (Seward,  1987) . 

Length  Clauses.  Length  clauses,  like  the  features 
described  earlier,  allow  the  developer  to  tailor  his 
application  to  the  underlying  hardware.  They  take  advantage  of 
physical  characteristics  (such  as  word  length)  to  define  for 
data  types  more  efficient  representations  than  the  defaults 
(DoD,  1983:Ch  13,  3).  Because  of  the  execution  time  and 
storage  space  requirements  placed  on  many  embedded 
applications,  length  clauses  are  thus  necessary  (Seward,  1987). 

Interfaces  to  Other  Languages.  Because  embedded 
applications  in  Ada  still  currently  need  to  call  assembly  and 
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JOVIAL  routines  to  perform  certain  low-level  operations 
(Bennett,  1987) ,  without  this  feature,  Ada  could  not  now  be 


used  for  embedded  applications. 

Other  features  in  Chapter  13  were  not  studied  because  they 
could  be  worked  around  more  easily  or  were  too  risky  to  use  in 
embedded  applications  (Bennett,  1987;  Roark,  1987;  Seward, 

1987).  Change  of  representation,  a  feature  that  allows  the 
developer  to  specify  an  alternate  representation  for  a  data 
type,  was  not  studied  because  its  function  could  be  provided 
(albeit  less  efficiently)  by  explicit  type  conversions  and 
declarations  of  additional  data  types.  Machine  code  insertions 
allow  the  developer  to  place  assembly  language  instructions 
directly  in  a  procedure,  but  the  same  result  may  be  obtained  by 
calling  an  assembly  language  routine  with  the  interface  to 
other  languages  feature.  Unchecked  storage  deallocation,  used 
to  free  for  further  use  memory  that  had  been  previously 
dynamically  allocated,  was  not  studied  because  the  developers 
either  do  not  have  the  high  confidence  in  the  correct  operation 
of  the  feature,  or  cannot  make  the  required  determination  of 
the  maximum  dynamic  memory  requirements,  or  both.  (Bennett, 
1987;  Seward,  1987).  Finally,  unchecked  type  conversion  was 
not  studied  because  it  would  not  be  used  as  often  as  the  other 
features  identified  for  study  (Bennett,  1987). 


Ada  LRM  (AJPO,  1987) .  This  requirement  is  expanded  in  the  ACVC 
Implementers ’  Guide  (AIG)  (described  in  Chapter  2)  in  specific 
design  guidelines  for  tests  for  the  entire  Ada  language 
(Goodenough,  1986) .  In  particular,  Ada  validation  tests  must 
clearly  state  their  objectives,  identify  the  language  feature 
being  tested,  and  generate  specific  information  on  whether  the 
compiler  passed  or  failed  the  test.  For  such  generation,  my 
validation  tests  used  the  standard  ACVC  test  reporting  package 

REPORT  that  wrote  the  results  of  the  tests  using  Ada’s  package 

2 

TEXT_IO  The  reasons  for  this  were  twofold:  by  designing  for 
re-usability  of  existing  software,  I  was  able  to  spend  more 
time  developing  and  testing  my  design;  and  this  approach  made 
the  tests  I  developed  reusable  by  organizations  such  as  the  Ada 
Validation  Facility  (AVF) .  The  validation  tests  were  likewise 
categorized  according  to  the  six  ACVC  test  classes  described  in 
Chapter  2  . 

While  validation  tests  provide  only  a  yes  or  no  answer  for 
implementations  of  a  Chapter  13  feature,  these  tests  are  a 
prerequisite  for  evaluating  the  performance  of  the  feature.  An 
efficiency  test  comparing  two  compilers  may  have  no  meaning  if 
one  of  the  compilers  being  tested  has  an  invalid  implementation 
of  the  feature  in  question. 

A  compiler  either  implemented  a  feature  correctly  and 
passed  all  validation  tests,  or  it  failed  one  or  more  of  the 

2 

TEXT_IO  can  be  used  for  this  purpose,  because  all  Ada 
compilers  must  implement  TEXT_IO  to  pass  a  compiler  validation 
( Wi 1  son ,  1987a)  . 


tests  and  was  ruled  non-valid.  Therefore,  statistical  methods 


could  not  be  applied  to  the  validation  tests  to  determine  their 
validity.  The  validity  of  the  tests  was  determined  instead 
through  reviews  of  the  tests  by  A CVC  test  developers  in  the  Ada 
Validation  Facility  and  at  SofTech,  Inc.  These  two 
organizations  are  responsible  for  the  development  and 
maintenance  of  all  tests  in  the  A CVC  test  suite  (Wilson, 

1987b) .  These  reviews,  identical  to  those  conducted  to  certify 
A CVC  tests,  ensured  that  test  design  objectives  were  fulfilled 
and  that  the  tests  contained  no  obvious  errors. 

Performance  Evaluation  Test  Requirements/Design 

The  two  metrics  described  in  chapter  2  that  were  used  to 
determine  the  efficiency  of  Chapter  13  features  in  embedded 
applications  were  memory  use  and  execution  speed.  Additional 
requirements  for  benchmarks  for  these  language  features  are: 

1.  The  features  to  be  measured  must  be  isolated  and 
compiler  optimizations  that  would  invalidate  the 
measurement  must  be  avoided. 

2.  Sufficient  accuracy  in  the  measurement  must  be 
obtained. 

3.  Operating  system  distortions  must  be  avoided. 

4.  The  results  obtained  must  be  repeatable  (Clapp 
and  others,  1986:760-761). 

As  the  research  progressed,  it  became  apparent  that  the 
time  metric  was  more  important  in  determining  the  efficiency  of 
Chapter  13  features,  because  the  MIL-STD- 1750A  extended  memory 
option  allows  an  application  to  address  up  to  one  megaword  of 
memory,  reducing  the  space  constraints  on  many  embedded 
applications.  Therefore,  this  thesis  concentrated  on 
benchmarks  that  measured  the  execution  time  associated  with  the 


use  of  a  Chapter  13  feature  as  a  metric  for  the  efficiency  of 
that  feature's  implementation. 

The  design  of  a  test  of  the  performance  of  a  Chapter  13 
feature  was  based  on  the  ‘dual-loop’  method  of  Clapp  and  others 
described  in  Chapter  2.  This  approach  concentrates  on 
measuring  the  effect  of  using  one  feature  and  meticulously 
negates  all  other  factors  that  may  affect  the  timing  results. 
This  is  the  best  method  for  determining  whether  a  compiler’s 
implementation  of  a  feature  is  suitable  for  an  embedded  real¬ 
time  application,  because  it  alone  (as  stated  in  chapter  2) 
provides  specific  comparative  information  about  the  effects  of 
the  use  of  that  one  feature.  Furthermore ,  it  is  the  same 
method  used  in  many  of  the  benchmarks  in  the  ACM  SIGAda  PIWG 
test  suite  (PIWG, 1986).  By  reusing  PIWG  software  for  timing 
measurements,  data  collection,  and  test  reporting,  I  had  more 
time  to  develop  and  validate  the  tests  for  performance 
evaluation  of  Chapter  13  features.  Numerical,  application 
domain,  and  synthetic  benchmarks  were  not  used  because  they 
could  not  provide  comparative  measures  of  compiler  efficiency 
for  specific  language  features. 

As  described  in  Chapter  2,  benchmarks  for  Chapter  13 
features  had  to  meet  additional  requirements.  The  isolation  of 
the  test  feature  was  accomplished  by  writing  two  parallel  sets 
of  executable  operations,  one  set  that  used  the  feature  and  one 
that  did  not.  Each  of  these  sets  was  placed  in  an  identical 
loop  so  that  the  only  difference  between  the  two  loops  was  the 
use  of  the  feature  being  studied. 


Test_Start_Time 

:=  Current_CPU_Time ; 

For  I  =  1  to  100 

loop 

Test_Var lable  :=  10; 
end  loop; 

Tes t_S top_Ti me  : 

=  Current_CPU_Time ; 

Test_Total_Time 

:=  Test_Stop_Time 

-  Test_Start_Time  ; 

Figure  1.  Benchmark  Test  Loop 

The  objective  of  this  test  is  to  measure  the  time  it  takes  to 
perform  an  assignment  statement  100  times  in  a  loop.  The 
Test_Start_Time  and  Test_Stop_Time  variables  take  time  readings 
before  and  after  the  loop  from  the  function  Current_CPU_Time , 
and  the  total  time  for  the  test  is  determined  by  their 
difference.  Because  the  value  of  Tes t_Var i abl e  will  be  10  no 
matter  how  many  times  the  loop  is  executed,  an  optimizing 
compiler  may  generate  executable  statements  that  will  perform 
the  operations  shown  in  figure  2.  In  this  optimized  version, 
the  assignment  has  been  moved  out  of  the  loop  by  the  compiler 
to  make  the  program  more  efficient.  Some  compilers  may  even 
remove  the  loop  entirely,  replacing  it  with  the  Tes t_Var i ab 1 e 
assignment  statement.  The  segment  of  code  in  figure  2  has  the 
same  logical  result  (i.e.  Tes t_Var i abl e  is  set  to  2)  as  the 
segment  of  code  in  figure  1,  but  the  results  of  the  execution 
time  measurement  may  be  very  different. 


Test_Start_Time  :=  Current_CPU_Tlme ; 

For  I  =  1  to  100  loop 

null;  --  Do  nothing  in  the  loop 
end  loop; 

Tes t_Var i ab 1 e  :=  10; 

Test_Stop_Ti me  : =  Curr ent_CPU_T ime ; 
Test_Total_Time  :=  Tes t_S top_Ti me 

-  Test_Start_Time ; 


Figure  2.  Optimized  Benchmark  Test  Loop 

Some  compilers  allow  the  user  to  control  optimization  by 
setting  a  parameter  for  the  compilation,  instructing  the 
compiler  to  perform  no  optimization  on  the  instructions. 

Another  method  is  to  keep  the  values  of  objects  in  the  loop 
hidden  from  the  compiler  by  placing  them  in  a  procedure  that  is 
compiled  after  the  test  program.  This  method  was  used  in  this 
thesis  because  it  ensured  no  optimization,  whether  an 
optimization  control  switch  was  set  or  not. 

The  accuracy  of  the  time  measurement  is  a  function  of  the 
resolution  of  the  clock  available  on  the  computer  on  which  the 
benchmark  is  run.  A  benchmark  that  is  generic  enough  to  run  on 
a  number  of  compilers  must  use  the  Ada  CLOCK  function  in 
package  CALENDAR,  because  it  is  the  only  function  that  all  Ada 
compilers  must  implement  that  returns  the  current  CPU  time  of 
the  underlying  hardware  (DoD,  1983:Ch  9,  11).  Such  use  of  the 

Ada  CLOCK  function  presents  a  number  of  timing  anomalies  that 


must  be  accounted  for  when  designing  a  benchmark:  Insufficient 


clock  precision,  variations  in  the  clock,  and  clock  overhead 
(Altman,  1987: 11-16) . 

The  CLOCK  function  in  Ada  does  not  provide  a  continuous 
representation  of  time:  rather,  it  expresses  the  time  in 
increments  t,  with  t  defined  by  the  value  SYSTEM. TICK  (DoD, 
1983:Ch  13,  11).  The  execution  time  of  a  benchmark  therefore 

will  always  return  a  time  of  some  integral  multiple  of  this 
increment,  n  »  t.  Because  the  actual  time  a  benchmark  takes  to 
execute  may  not  be  an  exact  multiple  of  t,  the  actual  time  will 
lie  between  n  *  t  and  (n  +  1)  *  t.  The  smaller  n  is,  the 
larger  the  variability  of  the  benchmark's  results.  By 
increasing  the  number  of  the  loop  executions,  this  variability 
can  be  reduced  and  a  more  accurate  time  for  the  effect  of  the 
feature  can  be  produced  by  averaging  the  time  for  one  execution 
(loop)  of  the  benchmark  (Clapp  and  others,  1986:762);  this  was 
the  method  used  in  this  thesis. 

In  the  course  of  this  research,  I  found  that  the  CLOCK 
function  did  not  return  time  values  with  the  precision 
necessary  to  measure  the  events  associated  with  the  features  I 
was  studying.  I  then  wrote  package  TIME_PACKAGE_ 1750A ,  which 
includes  procedure  GET_ALL_TI MES ,  designed  to  retrieve  the  time 
from  the  hardware  clock  registers  of  the  MI L- STD- 1 750A 
processor.  This  package  and  its  development  are  described  in 
detail  in  Appendix  F. 

Although  GET_ALL_TI MES  returns  CPU  times  with  greater 


precision  than  those  from  the  CLOCK  function  in  package 
CALENDAR,  it  too  is  affected  by  the  d i scr e te- f unc t i on  timing 


anomalies  described  above.  Furthermore,  a  clock  may  drift,  or 
gradually  run  slow  or  fast  compared  to  an  ideal  clock;  or  a 
clock  may  jitter,  speeding  up  or  slowing  down  briefly,  but 
remaining  accurate  over  longer  time  spans  (Altman,  1987; 12- 
lb)  .  Without  performing  tests  on  the  computer  hardware  with 
another  clock,  one  cannot  detect  drift  and  Jitter  but  should  be 
aware  that  they  may  occur.  Jitter  in  a  clock  will  tend  to  be 
offset  as  the  number  of  loop  iterations  increases  and  longer 
time  spans  are  used  to  record  the  results  of  the  benchmark. 

One  approach  to  negate  the  effects  of  drift  is  to  repeat  the 
benchmarks  a  number  of  times,  so  that  the  drift  of  a  clock 
would  apply  equally  to  the  test  and  control  loops  of  a 
benchmark,  still  providing  a  comparative  measure  of  compiler 
performance.  The  alternative  to  this  is  to  measure  the  drift 
of  the  clock  with  tests  on  the  computer  hardware  (e.g. , 
connecting  an  external  clock  to  the  computer  and  measuring  the 
differences  in  the  two  clocks) ,  or  to  use  an  external  clock  to 
record  benchmark  timing  data  (Altman,  1987:16) .  Detecting  the 
drift  of  a  clock,  if  it  existed,  was  beyond  the  scope  of  this 
thesis.  The  benchmark  executions  were  repeated,  however,  so 
that  if  drift  were  present,  its  effect  would  be  negated  as 
described  above. 

Overhead  in  the  GET_ ALL_TI MES  calls  was  negated  by  making 
identical  calls  for  a  test  and  control  loop  in  the  benchmark, 
so  that  when  the  elapsed  time  was  calculated  by  subtracting  the 
clock  start  time  from  the  clock  stop  time,  the  overhead 


introduced  by  the  GET_ALL_TI MES  call  was  eliminated  (Altman, 
1987 :  16)  . 


As  a  mechanism  for  verifying  that  the  GET_ALL_TIMES 

procedure  was  providing  an  accurate  measure  of  the  time 

required  for  the  test  execution,  GET_ALL_TIMES  and  the  Ada 

CLOCK  function  were  used  to  time  identical  loops  that  performed 

an  assignment,  addition,  and  conditional  ( j f - then- e 1 se) 

statement.  Techniques  for  control  of  optimization,  described 

earlier,  were  used  in  the  design  of  the  loops,  thus  the 

execution  times  should  have  been  identical.  Two  separate 

programs  were  written,  identical  except  for  the  routine  used  to 

retrieve  the  current  CPU  time.  The  programs  executed  the  loop 

3 

30,000  times  and  were  both  executed  50  times  on  a  Sperry  1631 
MI L - STD- 1 750A .  The  elapsed  loop  time  was  found  by  subtracting 
the  overhead  of  the  CPU  time  retrieval  calls  from  the  elapsed 
loop  time.  The  results  are  reported  in  table  1  below. 

Table  1 

GET  ALL  TIMES  and  CLOCK  Execution  Times 


Standard 

Time  Retrieval 

Mean 

Devi  at  ion 

Program 

( seconds ) 

(seconds ) 

GET_ALL_TIMES 

0.55158 

0 . 00028 

Ada  CLOCK 

0 . 525  10 

0. 00317 

Use  of  this  processor  does  not  necessarily  indicate  the 
compilers  studied  in  this  thesis.  The  Sperry  1631  processor 
executed  test  programs  compiled  with  at  least  three  validated 
Ada  compilers  targeted  to  the  MI L- STD- 1 750A  during  my  research. 


The  variability  in  the  results  may  be  attributed  to  the  reduced 
precision  available  with  the  CLOCK  function.  Package  CALENDAR 
reports  all  times  using  a  fixed  point  data  type  name  DURATION, 
which  stores  time  data  accurate  to  200  microseconds.  The 
OET_ALL_TIMES  procedure  can  retrieve  and  store  time  data 
accurate  to  10  microseconds.  Given  that  GET_ALL_TI MES  reports 
current  CPU  time  more  accurately  and  precisely  than  the 
function  available  in  package  CALENDAR,  GET_ALL_TIMES  was  used 
in  the  remainder  of  the  research  for  CPU  time  retrieval. 

The  third  additional  requirement  of  the  dual-loop  method, 
eliminating  operating  system  distortion,  is  not  a  major  concern 
with  the  MIL-STD- 1750A  computer.  This  requirement  was  included 
principally  for  time-sharing  or  multiprocessing  systems  in 
which  other  processors  or  system  functions  may  interfere  wit*' 
the  operation  of  the  benchmark  (Clapp  and  others,  1986:763). 
With  the  MIL-STD- 1750A ,  such  distortion  was  eliminated  by 
running  the  benchmark  and  nothing  else  on  the  computer. 

Finally,  repeatability  of  test  results  was  provided  in  the 
design  by  making  no  assumptions  about  pre-conditions  for  the 
benchmarks.  The  benchmarks  were  designed  to  run  alone  on  a 
MI L- STD- 1 750A ,  therefore  all  benchmark  executions  will  report 
identical  results. 


Summar: 


This  chapter  identified  the  most  important  features  in 


Chapter  13  for  study  and  described  why  they  are  important.  The 
requirements  for  validation  and  performance  evaluation  tests 


for  these  features  were  presented,  followed  by  a  description  of 
how  the  test  design  was  based  on  the  requirements.  In  the  next 
chapter,  the  system  design  presented  here  is  expanded  to  give 
more  details  of  the  design  process. 


Detailed  Design  of  Chapter  13  Feature  Tests 


This  chapter  provides  more  details  of  the  design  of  the 
validation  and  performance  evaluation  tests  for:  (1)  the 
prototype  Chapter  13  feature,  enumeration  representation 
clauses,  and  (2)  the  other  Chapter  13  features  identified  as 
important  to  embedded  applications  earlier  in  this  thesis, 
address  clauses  and  interrupts. 


Prototype  Test  Design 

The  enumeration  representation  clause  was  chosen  as  the 
feature  for  which  to  write  prototype  validation  and  performance 
evaluation  tests,  or  benchmarks,  because  of  its  current  and 
potential  use  in  embedded  applications  (Hanselman,  1987).  The 
purpose  for  writing  prototype  tests,  stated  in  the 
introduction,  was  to  develop  a  greater  unders tending  of  the 
requirements  for  and  the  problems  associated  with  design  and 
implementation  of  the  tests.  The  enumeration  representation 
clause  was  ideal  for  a  prototype  because  the  set  of  other 
language  features  it  affected  was  rather  small,  which  made 
tests  for  the  validity  and  performance  of  the  feature  much 
easier  to  develop.  Tackling  a  larger  or  more  extensive  feature 
first  would  have  consumed  more  research  time  for  the  amount 
learned  delaying  further  implementation  of  tests  on  other 
Chapter  13  features. 

Detailed  Prototype  Validation  Test  Design.  The  detailed 
design  guidelines  for  the  validation  tests  for  enumeration 
representation  clauses  came  from  the  ACVC  Implementers ’  Guide 


(AIG) ,  as  discussed  in  Chapter  3.  The  intent  in  the  design  of 
the  prototype  validation  tests  was  to  develop  and  execute  a 
representative  sample  of  tests  that  would  be  required  for  a 
complete  validation  of  the  feature.  The  purpose,  again,  was  to 
learn  as  much  about  the  process  of  developing  validation  tests 
and  the  problems  associated  with  this  development  as  quickly  as 
possible.  For  that  reason,  four  representative  tests  were 
written  for  the  13  test  objectives  outlined  in  the  AIG  for 
enumeration  representation  clauses  (Goodenough,  1986:Ch  13,  39- 
40) .  These  tests  were  selected  because  they  tested  the  feature 
as  it  would  most  commonly  be  used.  Tests  named  BD3001A, 
BD3002A,  BD3004A,  BD3012A  were  developed  to  test  objectives  1, 
2,  4  and  12  for  enumeration  representation  clauses.  The  names 
of  these  tests  conform  with  the  naming  conventions  for  the  A CVC 
test  suite  provided  by  the  Ada  Validation  Facility  (Wilson, 
1987a)  ,  making  this  work  more  understandable  to  and  usable  by 
those  familiar  with  the  AC VC.  A  description  of  the  ACVC  test 
objectives  for  validation  tests  in  this  thesis  is  found  at 
Appendix  A;  a  description  of  the  test  naming  conventions, 
sample  source  code  for  the  tests,  and  instructions  on  how  to 
obtain  mach 1 ne - r eadab 1 e  copies  are  at  Appendix  B. 

All  of  the  tests  developed  were  Class  B  tests:  that  is,  a 
compiler  with  a  valid  implementation  of  this  feature  should 
generate  compile-time  errors  for  the  test,  because  of  the 
test’s  illegal  use  of  the  enumeration  representation  clause. 
Class  B  tests  were  developed  because  a  majority  of  the  test 
objectives  for  enumeration  representation  clauses  in  the  AIG 


optimization;  (2)  would  be  accurate;  (3)  avoided  operating 
system  distortions;  and  (4)  would  be  repeatable. 

The  enumeration  representation  clause  was  isolated  by 
declaring  two  identical  enumeration  types  (one  control  and  one 
test)  specifying  a  representation  different  than  the  default 
representation  given  by  the  compiler  for  the  test  enumeration 
type,  and  allowing  the  control  enumeration  type  to  take  the 
default  representation.  By  performing  identical  operations  on 
objects  declared  using  the  test  and  control  types  in  a  loop  and 
measuring  the  difference  in  the  two  loops’  execution  times,  the 
execution  time  associated  with  the  use  of  the  enumeration 
representation  clause  could  be  determined. 

Potential  compiler  optimization  of  the  test  was  controlled 
by  a  method  used  in  the  PIWG  benchmarks,  shown  in  an 
abbreviated  form  in  figure  3.  GLOBAL,  A_ONE ,  and  the  procedure 
REMOTE  are  declared  in  package  REMOTE_GLOBAL ,  whose  body  is 
compiled  after  that  of  the  benchmark,  thus  the  values  of  A_ONE 
and  GLOBAL  will  now  always  be  known  to  the  compiler  when  the 
benchmark  is  compiled.  Therefore,  the  sequence  of  statements 
in  the  benchmark  cannot  be  changed  by  an  optimizing  compiler, 
because  the  effect  of  the  optimization  could  alter  the  logical 
results  of  the  code. 

Methods  for  eliminating  operating  system  interference  from 
paging  and  execution  of  other  processes  have  little  to  do  with 
the  design  of  the  benchmark  itself,  but  rather  with  the 
environment  in  which  the  test  will  be  run.  Benchmark  tests 
should  be  run  on  a  system  with  no  other  user  processes  in 
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package  REMOTE_GLOBAL  is  --  for  explicit  control 
A_ONE  :  INTEGER;  --  of  optimization 

GLOBAL  :  INTEGER  :=  1  ; 
procedure  REMOTE; 
end  REMOTE_GLOBAL  ; 

with  REMOTE_GLOBAL ;  use  REMOTE_GLOBAL ; 

procedure  TEST  is 

begin 

for  loop_counter  in  1  . .  100  loop 

GLOBAL  :=  GLOBAL  +  A_0NE ; 

REMOTE ; 

<Test  feature  statements) 
end  loop ; 
end  TEST; 

package  body  REMOTE_GLOBAL  is  --  must  be  compiled  last 
LOCAL  :  INTEGER;  --  will  be  set  to  0  at  elaboration 
procedure  REMOTE  is 
beg  i  n 

GLOBAL  : =  GLOBAL  +  LOCAL; 
exception 

when  NUMERI C_ERROR  =>  REMOTE  ; 

--  cannot  happen  if  test  is  working 
end  REMOTE;  --  (  prevents  inlining  ) 

beg  i  n 

A_ONE  : =  1  ; 

LOCAL  :=  GLOBAL  -  A_ONE ;  --  really  a  zero  but 

end  REMOTE_GLOBAL ;  --  compiler  doesn't  know 


Figure  3.  PIWG  Optimization  Control  Package 


concurrent  execution  and  with  as  many  system  processes  disabled 
as  possible  (Clapp  and  others,  1986:  764).  I  eliminated  much 
of  the  operating  system  interference  by  keeping  the  size  of  the 
benchmark  small  (to  reduce  paging)  and  by  running  the  benchmark 
when  the  host  computer  had  a  low  load,  to  reduce  the  effect  of 
other  processes  on  the  timing  results  from  the  benchmark. 

Although  the  prototype  test  was  to  be  run  on  a  time¬ 
sharing  system,  I  did  not  eliminate  all  operating  system 


interference.  The  goal  of  this  thesis  was  to  develop 
benchmarks  for  compilers  targeted  to  embedded  computers. 
Operating  system  interference  is  not  a  problem  with  these 
systems  because  the  user  has  much  greater  control  over  the  run 
time  library  (or  operating  system)  and  can  ensure  that  only  the 
benchmark  is  running  when  testing  the  compiler. 

Repeatability  of  the  tests  was  built  into  the  benchmark  by 
providing  a  sound  performance  data  reporting  capability  and  by 
making  no  assumptions  about  a  set  of  conditions  before  the  test 
started.  Repeatability  of  the  test  was  proven  in  its  actual 
use  . 

The  PIW3  benchmarks  and  benchmark  support  software  were  of 
great  use  in  the  design  for  collection  of  timing  data  and  for 
avoiding  optimization  of  the  test  programs.  A  description  of 
the  PIWG  software  used  in  this  thesis  and  instructions  on  how 
to  obtain  mach i ne - readab 1 e  copies  may  be  found  at  Appendix  C. 
Using  the  design  philosophy  of  the  PIWG  benchmarks ,  I  designed 
a  performance  benchmark  that  consisted  of  (1)  a  control  loop 
containing  an  operation  on  an  enumeration  object  without  the 
use  of  an  enumeration  representation  clause;  and  (2)  a  test 
loop  containing  an  operation  on  an  enumeration  object  that  used 
an  enumeration  representation  clause.  This  dual-loop  approach, 
as  described  in  Chapter  3,  is  superior  to  others  because  it 
isolates  the  feature  and  eliminates  the  time  associated  with 
overhead,  such  as  loop  control. 


The  design  of  this  test,  shown  in  figure  4,  was  modeled 
after  test  designs  for  other  Ada  language  constructs  in  the 
PIWG  suite  of  benchmarks  (PIWG,  1986) .  In  this  design  the 


Control_Time_Start 

: =  SECONDS (CLOCK) ; 

while  (condition) 

loop 

(optimization 

control  statements) 

(control  version  of  feature)  j 

end  loop; 

Control_Time_Stop 

:=  SECONDS (CLOCK) ; 

Tes t_T i me_S tar t  := 

SECONDS (CLOCK) ; 

while  (condition) 

loop 

(optimization 

control  statements) 

(test  version 

of  feature) 

end  loop; 

Test_Time_Stop  := 

SECONDS (CLOCK) ; 

D i f f er ence_T i me  := 

(Test_Time_Stop 

-  Test_Time_Start)  - 

( Con tr o 1 _T i me_S top  -  Control_Time_Start) ; 

Figure  4.  Performance  Benchmark  Structure, 
current  CPU  time  is  retrieved  from  the  SECONDS ( CLOCK )  function 
(DoD,  1983:Ch  9,  11)  before  execution  of  the  control  loop.  The 

control  loop  will  be  executed  a  sufficient  number  of  times  to 
obtain  the  timing  accuracy  desired.  Optimization  control 
statements,  as  described  earlier,  are  placed  in  the  control 
loop,  followed  by  statements  that  do  not  use  the  feature  being 
studied.  At  the  end  of  the  control  loop,  the  current  time  is 
again  retrieved  The  test  loop  is  identical  to  the  control 
loop  except  that  the  feature  being  studied  is  used  in  the  test 
loop  statements.  The  calculation  at  the  end  of  the  test 
removes  all  bias  associated  with  the  loop  overhead  and  calls  to 
the  clock  function,  leaving  the  time  associated  with  the  use  of 
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the  feature.  This  calculation  assumes  that  the  test  loop  will 
take  longer  to  execute  than  the  control  loop  since  use  of  the 
feature  is  normally  assumed  to  add  complexity  to  the  test 
loop.  It  is  possible  that  the  default  (or  control)  use  of  the 
features  is  less  efficient  than  the  test  use  of  the  feature. 

In  such  cases,  one  should  determine  the  absolute  value  of  the 
difference  to  determine  the  increase  in  performance 
attributable  to  the  test  version  of  the  feature. 

Problems  in  Prototype  Test  Design  and  Certification. 

Recall  that  the  Ada  LRM  states,  "An  implementation  may  limit 
its  acceptance  of  representation  clauses  to  those  that  can  be 
handled  simply  by  the  underlying  hardware’  (DoD,  1983:Ch  13, 

2) .  Therefore,  although  an  implementation  may  implement  a 
feature  such  as  enumeration  representation  clauses,  that 
implementation  may  restrict  how  the  feature  may  be  used.  These 
restrictions,  in  turn,  may  cause  some  validation  tests  to  be 
inapplicable  for  that  implementation.  If  a  test  is  ruled 
inapplicable,  the  test  is  not  run  when  the  compiler  is 
validated.  For  example,  an  implementation  for  enumeration 
representation  clauses  may  allow  the  clause  for  explicitly 
declared  enumeration  types,  but  not  for  derived  types.  Any 
validation  tests  for  derived  types  would  therefore  be 
inapplicable,  and  the  compiler  simply  would  not  be  tested  in 
that  area. 

The  difficulty  ruling  certain  tests  inapplicable  is  that 
where  a  number  of  sub-objectives  are  listed  for  one  test 
objective,  separate  test  procedures  must  be  written  for  each 


sub- ob j ec t i ve ,  because  some  of  the  sub- ob j ec t 1 ves  may  be 
inapplicable.  For  instance,  in  the  example  presented  earlier, 
if  a  test  procedure  tested  enumeration  representation  clauses 
for  both  explicitly  declared  and  derived  types,  the  test  would 
be  declared  inapplicable,  even  though  the  compiler  implemented 
enumeration  representation  clauses  for  explicitly  declared 
types.  Because  compilers  may  provide  no,  partial,  or  full 
implementation  of  a  feature,  validation  tests  must  be  designed 
to  test  all  possible  implementations.  This  makes  the  number  of 
tests  that  must  be  written  increase  dramatically  as  the  number 
of  sub - ob j ec t i ves  of  a  validation  test  objective  increases. 

A  seeming  flaw  in  the  application  of  this  benchmarking 
approach  is  the  assumption  that  use  of  a  feature  in  an 
application  will  cause  the  execution  time  for  a  sequence  of 
statements  using  the  feature  to  increase.  This  may  not  be  the 
case.  In  fact,  preliminary  test  of  the  benchmarks  for 
enumeration  representation  clauses  showed  the  test  loop  took 
less  time  to  execute  than  the  control  loop,  resulting  in  a 
negative  time  difference  between  the  loops.  Other  researchers 
have  found  similar  anomalies  using  the  dual-loop  method 
(Alt  ma  n ,  1987:3)  . 

The  flaw  is  not  in  the  dual-loop  method,  but  in  how  it  is 
applied.  In  the  prototype  benchmarks,  I  was  unable  to 
eliminate  interference  from  the  operating  system,  which 
distorted  the  benchmark’s  execution.  When  the  dual-loop 
benchmarks  were  executed  on  embedded  computers  (with  no 


operating  system  interference)  these  timing  anomalies  were 


eliminated  (Klemens,  1987)  . 

Address  Clauses  and  Interrupts  Test  Design 

Now  that  the  description  of  prototype  test  detailed  design 
has  been  completed,  let  us  proceed  to  describe  the  detailed 
design  of  the  actual  experimental  tests. 

Detailed  Validation  Test  Design.  As  stated  earlier,  the 
design  objectives  were  taken  from  the  AC VC  Implementers ’ 

Guide.  The  23  test  objectives  test  the  ability  of  a  compiler 
to  detect  illegal  uses  of  the  address  clause  and  to  permit 
legal  uses  of  the  clause.  All  developed  tests  should  be  passed 
by  a  compiler  providing  a  full  implementation  of  the  address 
clause.  Therefore,  class  A  or  class  B  test  programs  were 
written  for  all  test  objectives.  The  class  A  tests  do  not 
contain  run-time  checks  for  use  of  the  address  clauses,  but  I 
verified  that  these  could  easily  be  changed  to  class  C  (run¬ 
time)  tests  by  checking  that  the  addresses  given  for  the 
objects,  subprograms,  etc.  in  the  test  are  consistent  with  the 
addresses  given  by  the  ’ADDRESS  attribute  applied  to  the  same 
objects,  subprograms,  etc.  during  the  test  execution  (DoD, 
1983:Chl3,  12) .  No  other  classes  of  tests  could  be  reasonably 

applied  to  this  feature,  since  it  affects  only  the  location  of 
objects  and  executable  statements  when  the  test  is  compiled. 

Detailed  Performance  Evaluation  Test  Design.  The 


interrupts  feature  to  respond  to  an  interrupt,  because  this 
time  is  critical  to  embedded  applications  (Clapp  and  others, 
1986:771) .  The  objective  of  these  benchmarks  was  to  measure 
the  delay  between  the  time  the  interrupt  is  raised  and  the  time 
the  interrupt  handling  routine  is  entered  (Seward,  1987) . 

Recall  from  Chapter  3  that  the  interrupts  feature  of  Ada 
allows  an  application  to  associate  an  interrupt  with  a  task 
entry,  so  that,  when  the  interrupt  occurs,  the  task  entry  is 
called  and  the  accept  block  for  the  entry,  if  any,  is 
executed.  The  detailed  design  of  these  benchmarks  was  based  on 
three  variables  in  designs  using  this  feature:  (1)  the  number 

of  interrupts  that  will  be  handled,  (2)  the  number  of  tasks 
that  will  be  used  to  handle  these  interrupts,  and  (3)  the 
number  of  entries  in  each  of  the  interrupt  handling  tasks. 

The  semantics  of  Ada  tasking  allow  developers  to  write  one 
task  with  several  entry  points,  several  tasks  with  one  entry, 
or  any  combination  in  between  to  handle  the  16  possible 
Interrupts  that  MIL-STD- 1750A  computers  may  generate  (DoD, 

1982: 19) .  Table  II  shows  the  configuration  of  the  the 
benchmarks  designed  for  this  feature.  In  all  of  these  tests 
only  one  interrupt  is  raised,  that  of  a  floating  point 
overflow,  generated  by  the  benchmark  itself.  In  order  to 
Isolate  and  study  the  interrupt  delay  time  associated  with  one 
interrupt  (i.e.,  floating  point  overflow),  I  designed  the 
benchmarks  so  that  only  one  interrupt  could  cause  a  call  to  a 
task  entry.  If  task  entries  had  been  associated  with  other 


Table  II 

Interrupts  Benchmark  Configuration 


Test 

Name 

Interrupts 
Hand 1 ed 

Tasks 

Entries 
per  Task 

I  NT_ 

TEST  1 

10 

10 

1 

I  NT_ 

TEST2 

10 

5 

2 

I  NT  _ 

TEST3 

10 

2 

5 

I  NT 

TEST4 

)  0 

1 

10 

I  NT_ 

TEST5 

3 

3 

1 

I  NT 

TEST6 

3 

1 

3 

I  NT_ 

TEST7 

1 

1 

1 

r  u  p  t  s  t  h  a 

t  are 

known  to  occur 

during  a 

program ’ s 

execution  .  these  other  interrupts  could  have  had  an  affect  on 
*he  delay  t *  me  of  the  interrupt  being  studied.  For  this 
reas.r  six  of  the  MI L - STD -  1 7 50 A ’ s  16  interrupts  were  not 
associated  with  task  entries  in  the  benchmarks  developed. 

I  r.  t  err  up*.  5  'executive  call),  interrupt  7  (timer  A  interrupt), 
and  interrupt  9  (timer  B  interrupt)  were  not  handled  because 
•hey  would  occur  too  frequently;  interrupt  0  (power  down) , 
interrupt  1  'machine  error) ,  and  interrupt  15  (spare)  should 
•  '  *  he  handled  by  an  application. 

INT_TE£T1,  I NT_TEST2 ,  I NT_TEST3 ,  and  I NT_TEST4  were 
des.gr.ed  to  determine  the  effect  the  number  of  tasks  and 
entries  per  task  had  on  interrupt  response  time.  One  would 
expert  that  variability  in  these  results  would  come  from  the 
increased  overhead  Incurred  by  the  task  scheduler  for  the 
benchmarks  with  a  h.gh  number  of  tasks.  On  the  other  hand,  the 
rendezvous  logic  for  those  tasks  with  single  entry  points  is 
.ess  complicated  and  should  be  more  efficient. 


INT_TEST5,  and  INT_TEST6  were  designed  to  Study  the  Same 
effects  but  restricting  the  interrupts  that  were  handled  in  the 
application  to  only  those  interrupts  that  were  expected  to 
occur  during  the  execution  of  floating  and  fixed  point 
instructions.  Again,  the  effect  of  the  number  of  tasks  and 
entries  per  task  on  interrupt  response  time  was  examined. 

Finally,  INT_TEST7  was  designed  as  a  baseline  against 
which  the  other  benchmarks  may  be  compared.  It  contains  the 
minimal  number  of  tasks,  entries,  and  interrupts  handled. 

The  benchmarks  were  all  designed  to  raise  the  floating 
point  overflow  interrupt  (interrupt  3)  (DoD,  1982:19)  by  adding 
one  floating  point  object  whose  value  is  just  below  the  largest 
floating  point  number  that  may  be  stored  to  another  floating 
point  object  whose  value  is  such  that  the  operation  causes  an 
overflow.  No  matter  what  the  task/entry  mix  of  the  benchmark, 
at  least  one  task  entry  will  have  an  address  clause  that  ties 
the  entry  to  MIL-STD- 1750A  interrupt  3.  The  example  shown  in 
figure  5,  an  abbreviated  version  of  INT_TEST7,  gives  the  format 
for  the  interrupt  delay  benchmarks.  A  call  is  made  to  a 
procedure  that  will  return  the  current  CPU  time  before  the 
floating  point  overflow  is  generated  in  the  main  procedure. 

The  floating  point  overflow  is  then  caused,  which  should 
effectively  generate  a  task  entry  for  the  task  entry  tied  to 
Interrupt  3.  The  accept  block  for  the  entry  is  then  entered, 
and  a  call  is  made  to  QET_ALL_TI MES  to  retrieve  the  CPU  time. 
This  time  value  is  then  stored  in  a  global  variable  that  is 
made  visible  to  the  task  and  the  main  procedure  through  the 


package  GLOBAL_ I NTERRUPT, MAKER  la 

function  FLOAT_R£TURN  return  float; 
end  GLOBAL, I  NT ERRUPT_ MAKER ; 

with  T I  ME _ PACK AGE _ 1 75  0 A ;  use  TIME_PACKAGE_ 1750A ; 
with  GLOBAL, I NTERRUPT, MAKER ; 
procedure  INT_TEST7  la 

float_object  : FLOAT : =  0.500000  »  2.0  »*  127; 


delay 

T I  ME, 1 7  50A 

=  0.0 

clock,bias_start 

T I  ME, 1 750A 

=  0.0 

clock,bias,stop 

TIME, 1750A 

=  0.0 

bef ore_interrupt 

TIME, 1 750A 

=  0.0 

after_interrupt 

TIME, 1 750A 

=  0.0 

pragma  SHARED (af ter, interrupt) ; 

taak  I NT_HANDLE_3  la 
entry  interrupt3; 
for  interrupt3  use  at  3; 
pragma  PRI0RITY(3) ; 
end  INT_HANDLE_3 ; 
task  body  INT_HANDLE_3  is 
begin 

loop 

accept  interrupts  do 

GET_ALL_T I MES (af ter_interrupt) ; 
end  interrupt3 ; 
end  loop; 
end  INT_HANDLE_3 ; 
begin  --  INT,TEST7 

for  l  in  1  . .  max_values  loop 

GET_ ALL_T I MES ( c 1 ock_bi as_s tar t ) ; 

GET,ALL,T I MES ( c 1 ock,bi as,s top)  ; 

GET_ALL_T I MES ( be f ore_ l n terr upt ) ; 
float_object  :=  f 1 oat_obj ect  + 

GLOBAL, I NTERRUPT, MAKER . FLOAT, RETURN ; 
delay  :=  af ter, interrupt  -  (bef ore_interrupt  + 
clock_bias_stop  -  c 1 ock,bi as,s tar t ) 

end  loop; 

abort  I NT_HANDLE_3 ; 
end  I NT_TEST7 ; 

package  body  GLOBAL, I NTERRUPT_MAKER  is 
function  FL0AT_RETURN  return  float  is 
begin 

return  0.50000  *  2.0  «»  127; 
end  FLOAT_RETURN ; 
end  GLOBAL, I NTERRUPT, MAKER ; 


Figure  5 . 


Example  Interrupt  Delay  Benchmark 


Ada  pragma  SHARED.  After  the  accept  block  of  the  task  entry 
has  finished  its  execution,  control  returns  to  the  loop  in  the 
main  procedure  and  the  interrupt  delay  time  is  determined.  By 
subtracting  the  time  for  a  call  to  the  GET_ALL_TI MES  routine, 
the  effect  of  the  timing  calls  may  be  eliminated.  A  sample  of 
the  benchmarks  developed  in  this  thesis  and  instructions  on  how 
to  obtain  machine-readable  copies  are  at  Appendix  C. 

Validation  Test  Design  Problems.  The  primary  difficulty 
with  writing  validation  tests  for  address  clauses  is  the 
representation  of  the  address  in  the  test.  The  syntax  of  the 
address  clause  is: 

for  simple  _name  use  at  s i mpl e _express i on ; 

(DoD ,  1983 : Ch  13 ,  7) . 

The  s imple  _express ion  specifies  the  address  for  the  entity 
given  by  simple _name  ,  and  the  expression  must  be  of  the 
i mp 1 emen tat i on -de f ined  type  ADDRESS,  declared  in  the  Ada 
Package  SYSTEM  (DoD,  1983:Ch  13,  7,10). 

While  an  address  given  in  the  address  clause,  whether 
interpreted  as  an  address  or  an  interrupt  level,  will 
ultimately  be  translated  to  some  physical  memory  address  on  the 
underlying  hardware,  the  type  ADDRESS  may  be  the  pre-defined 
Ada  type  integer,  positive,  natural,  access,  private,  limited 
private,  or  even  some  other  type  declared  by  the 

implementation.  Therefore,  validation  tests  had  to  be  designed 
in  such  a  way  that  addresses  were  not  explicitly  given  in  the 
tests.  Consider  the  simple  example  at  figure  6  of  an  address 
clause.  In  this  example,  an  object  of  type  integer  called 


Figure  6.  Address  Clause  Example 
counter  has  been  declared,  and  the  compiler  has  been  instructed 
to  store  counter  at  address  100.  This  is  legal  for  compilers 
that  recognize  100  as  a  valid  value  for  type  ADDRESS.  Another 
compiler,  with  a  correct  implementation  of  the  address  clause, 
may  reject  this  example  because  it  has  an  additional 
restriction  that  addresses  for  objects  be  greater  than  some  pre 
defined  number,  for  example,  1000.  Because  of  differences  in 
computer  architecture  and  restrictions  an  implementation  may 
place  on  address  clauses,  there  could  be  a  separate  set  of 
legality  rules  for  address  clauses  for  each  Ada  compiler.  The 
problem,  then,  is  how  to  write  syntactically  legal  validation 
tests  that  all  Ada  compilers  claiming  a  correct  implementation 
of  address  clauses  and  interrupts  could  pass . 

The  first  solution  is  to  write  tests  specifically  for  each 
implementation.  Currently  there  are  137  validated  Ada 
compilers,  and  the  number  is  growing  (AdalC,  1987).  Given  the 
number  of  Ada  compilers,  this  would  prove  to  be  unworkable 
because  it  would  severely  complicate  the  maintenance  of  the 
ACVC  test  suite,  as  well  as  running  counter  to  software 
engineering  principles  of  usability  and  portability. 

Another  solution,  and  one  that  has  been  used  in  tests  for 
other  implementation  defined  language  features  in  the  ACVC,  is 


to  replace  the  feature  with  a  macro  (Brashear,  1987a) ,  a 
symbolic  value  that  would  be  modified  by  each  implementation. 
The  example  in  figure  6  would  be  modified  as  shown  in  figure  7. 


counter:  Integer; 

for  counter  use  at  *object_address ; 


Figure  7.  Address  Clause  Example  with  Macro 
This  'master  version"  test  would  then  be  modified  by  each 
compiler  implementer  when  the  compiler  was  validated,  replacing 
Sobjec t_address  with  a  legal  address  for  his  implementation. 
This  approach,  although  workable,  would  be  cumbersome,  given 
the  fact  that  these  macros  may  appear  hundreds  of  times  in  the 
tests  for  just  one  language  feature. 

The  approach  used  to  retrieve  legal  addresses  in  this 
thesis  project,  then,  was  to  write  a  package  ADDRESS_PACKAGE 
that  declared  a  number  of  objects  of  type  ADDRESS  in  the 
visible  part  of  the  package.  A  number  of  objects,  subprograms , 
packages,  tasks,  and  task  entries  were  declared  in  declarative 
blocks  in  the  executable  region  of  the  task  body.  The 
addresses  for  all  these  entities  were  extracted  using  the 
'ADDRESS  attribute  (DoD,  1983:Ch  13,  12)  and  stored  in  the 
visible  address  objects.  Since  a  declaration  of  an  entity  in  a 
block  is  effective  only  for  the  duration  of  the  block,  it  was 
legal  to  reuse  these  addresses  because  the  entities  declared  in 
the  ADDRESS_PACKAGE  body  no  longer  existed  when  the  addresses 


were  used  in  a  validation  test.  This  worked  well  with  one 


compiler  that  placed  few  restrictions  on  the  simple  expression 
in  the  address  clause.  Another  compiler  restricted  the  address 
clause  to  static  values  that  must  be  set  when  the  compilation 
unit  in  which  the  address  clause  is  used  is  compiled.  For  this 
compiler,  constant  objects  of  type  ADDRESS  were  declared  and 
assigned  values  that  would  be  accepted  by  the  implementation. 
This  method  means  that  each  implementer  will  have  to  provide 
the  package  body  for  ADDRESS_PACKAGE  tailored  to  his 
implementation  when  running  the  validation  test  suite. 

While  this  approach  adds  another  package  to  the  ACVC  test 
support  software,  it  eliminates  the  need  for  large  number  of 
changes  to  ACVC  tests  that  would  be  required  to  tailor  those 
tests  to  a  particular  implementation,  and  eliminates  the  need 
for  tests  written  particularly  for  each  implementation. 

Another  problem,  discussed  earlier  with  enumeration 
represen  tat i on  clauses,  is  that  implementations  may  restrict 
the  use  of  address  clauses.  This  means  that  a  separate  test 
program  must  be  written  for  each  combination  of  sub-objectives 
of  a  test  objective.  For  example,  test  objective  11  for 
address  clauses  states: 

Check  whether  an  address  clause  can  be  given  for  an 
object  declared  in  a  declarative  part. 

Implementation  Guideline:  Use  a  variable  and 
constant  having  the  following  types:  enumeration, 
integer,  floating  point,  fixed  point,  array,  record, 
access,  private,  limited  private,  and  task. 

Implementation  Guideline:  Include  a  check  for 

declarative  parts  of  subprograms,  blocks,  and  package 
bodies  (Goodenough,  1986:Ch  13,  54). 


50 


Since  an  implementation  could  conceivably  restrict  its 


acceptance  of  address  clauses  to  those  given  for  integer 
variables,  20  test  programs  would  have  to  be  written  for  this 
test  objective,  because  there  are  20  different  combinations  of 
objects,  variables,  and  constants.  Each  of  the  sub-objectives 
would  have  to  be  written  as  a  separate  test,  because  any  test 
that  contained  a  use  of  the  feature  that  the  compiler 
restricted  would  be  ruled  inapplicable  (Wilson,  1987a).  Since 
each  compiler’s  implementation  may  vary  between  none  and 
complete,  the  tests  must  be  written  so  that  if  a  test  is  ruled 
inapplicable,  it  does  not  contain  a  test  for  a  use  of  the 
feature  that  the  implementation  does  support. 

Performance  Evaluation  Test  Design  Problems.  In  the 
course  of  this  research,  I  found  that  the  implementation  of 
package  CALENDAR  provided  by  the  compiler  being  used  to  develop 
the  benchmarks  did  not  return  the  current  CPU  time  with  the 
precision  necessary  to  accurately  measure  interrupt  delay 
time.  This  compiler’s  implementation  of  the  pre-defined  type 
DURATION  is: 

type  DURATION  is  delta  2.0  * «  (-  12) 

range  -86_400.0  86_400.0; 

The  current  CPU  time  value  returned  by  the  SECONDS  function  in 
package  CALENDAR  is  a  subtype  of  DURATION,  therefore  the  CPU 
time  is  accurate  only  to  244  microseconds.  Past  experience  has 
shown  other  interrupt  delay  times  to  be  in  the  10  to  100 
microsecond  range,  thus  the  precision  of  the  elapsed  CPU  time 
in  package  CALENDAR  was  inadequate  for  this  research.  An 
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alternative  package,  T I ME_PACKAGE_ 1 750A  was  written  that 
included  three  procedures:  GET_ALL_TIMES , 

RESET_ I NT_VECT0RS_7_AND_9 ,  and  GET_TI MERS ;  and  declared  a 
floating  point  type,  TIME_1750A.  GET_ ALL_T I MES  calls 
GET_TI MERS  to  retrieve  the  current  value  of  the  TI MER  A 
register  of  the  MI L-STD- 1 750A .  Because  the  TIMER  A  register  is 

incremented  every  10  microseconds  (DoD,  1982)  GET_ ALL_T I MES  can 
calculate  the  current  CPU  time  Cin  seconds)  by  dividing  the 
value  of  the  register  by  10,000  /  second.  If,  for  example,  the 
current  value  of  the  TIMER  A  register  was  1234,  the  elapsed 
time  since  TIMER  A  was  set  to  0  would  be  12,340  microseconds  or 
0.01234  seconds.  GET_ALL_TIMES ,  then,  was  able  to  return  the 
current  CPU  time  accurate  to  10  microseconds.  After  its 
correct  operation  was  verified,  the  GET_ALL_TIMES  procedure  in 
T I ME_PACKAGE_ 1 750 A  was  used  to  retrieve  CPU  time  in  the 
benchmarks  in  the  remainder  of  this  research.  Appendix  F 
contains  a  detailed  description  of  TIME_PACKAGE_ 1750A . 


Summary 

This  chapter  described  the  detailed  design  of  the 
validation  tests  and  benchmarks  developed  for  the  prototype 
feature,  enumeration  representation  clauses,  and  the 
operational  features,  address  clauses  and  interrupts. 

The  validation  tests  were  designed  to  test  a  compiler’s 
ability  to  recognize  legal  uses  of  the  feature  and  also  to 
detect  illegal  uses  of  the  feature.  The  problem  of  non¬ 
portability  of  the  tests  because  of  differing  implementations 


of  the  1 mp 1 emen tat  1  on -de f 1 ned  type  ADDRESS  was  solved  by 
placing  all  objects  of  type  ADDRESS  that  would  be  used  in  the 
validation  tests  in  one  package  and  having  the  implementer 
supply  the  package  body. 

The  benchmarks  for  interrupt  delay  time  measure  the  delay 
from  the  time  an  interrupt  is  caused  with  a  floating  point 
overflow  to  the  time  the  accept  block  of  the  interrupt  handling 
task  is  entered.  A  support  package,  TIME_PACKAGE_ 1750A ,  was 
developed  to  return  CPU  time  with  greater  precision  than 
available  with  the  implementation  of  package  CALENDAR  found  in 
the  compilers  used  in  this  research. 

The  next  chapter  will  validate  (or  certify)  the  approach 
and  the  tests  developed  in  this  research,  report  the  results  of 
the  tests,  and  analyze  the  results. 


V. 


Analysis  and  Results 

The  purpose  of  this  chapter  is  to  certify  the  test 
software  written  in  this  research  and  to  report  the  results  of 
the  validation  and  performance  evaluation  tests  for  the  Chapter 
13  features  studied.  I  will  use  the  term  "certification" 
instead  of  ‘validation"  to  avoid  confusion  with  the  validation 
tests.  The  certification  of  these  tests  will  ensure  that  the 
tests  do  indeed  test  what  they  claim  to  test. 

In  order  to  keep  the  potential  distribution  of  this  thesis 
as  wide  as  possible,  no  actual  compiler  names  will  be  used  when 
reporting  validation  or  benchmark  results.  The  compilers  that 
were  used  will  be  genencally  described  as  shown  in  table  III 
be  1 ow. 

Table  III 

Generic  Compiler  Description 


Compiler 

Host 

Target 

A 

DEC 

VAX- 1 1/780* 

DEC  VAX- 11/780 

B 

DEC 

VAX- 1 1/780 

MIL-STD- 1750A 

C 

DEC 

VAX- 1 1/780 

MIL-STD- 1750A 

All  of  the  compilers  used  in  this  thesis  were  validated  when 
the  research  was  performed.  The  benchmarks  developed  in  this 
thesis  were  executed  on  a  Sperry  1631  MIL- STD- 1 750A  processor. 


« 


VAX  is  a  trademark  of  Digital  Equipment  Corporation. 
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Certification  of  Validation  Tests 


This  section  will  certify  that  the  validation  tests 


written  in  this  thesis  will  indicate  whether  a  compiler’s 


implementation  of  address  clauses  and  interrupts  conforms  with 


the  spec i f 1  cat i on  for  those  features  in  the  LRM.  Recall  from 


Chapter  4  that  two  classes  of  validation  tests  were  written: 


Class  A  tests,  which  determine  a  compiler’s  ability  to 


recognize  legal  uses  of  a  feature,  and  Class  B  tests,  which 


determine  a  compiler's  ability  to  recognize  illegal  uses  of  a 


feature.  I  argue  that 


of  these  validation  tests 


arises  from  the  following  evidence:  the  design  of  the  tests 


was  made  as  simple  as  possible;  potential  for  error  in  the  use 


of  the  address  clause  was  minimized  by  localizing  all  address 


values  in  one  package;  all  non-address  clause  syntax  errors 


were  eliminated;  complex  test  cases  were  developed  separately; 


1 mp 1 emen tat  1  on -dependent  constructs  were  avoided;  and  finally, 


the  tests  were  reviewed  for  correctness  by  the  primary 


developers  of  tests  for  the  ACVC  test  suite.  Each  of  these 


contributions  to  test  certification  is  described  below. 


Test  Simplicity.  To  test  whether  a  compiler  could  use  a 


feature  under  a  specific  set  of  conditions,  the  validation 


tests  were  written  to  include  those  conditions  and  no  others 


lest  spurious  side-effects  be  introduced. 


Minimization  of  Error-Prone  Constructs.  This  technique 


was  used  to  certify  the  development  of  the  ADDRESS_PACKAGE  for 


the  address  clause  and  interrupts  tests.  Each  of  these  tests 


used  a  constant  or  variable  from  the  visible  part  of 
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ADDRESS_PACKAGE  for  the  address  of  a  construct  in  the  address 
clause.  By  declaring  all  addresses  in  one  package  and  using 
that  package  for  all  tests,  the  potential  for  error  in  the 
syntax  of  the  address  clause  was  greatly  reduced.  Such  use 
eliminated  the  need  to  enter  explicit  addresses  in  each  of  the 
many  (110)  tests,  while  ensuring  that  the  Ada  compiler  would 
detect  errors  such  as  misspelled  address  variable  names  by 
identifying  them  as  undeclared  variables,  since  all  variables 
must  be  explicitly  declared  in  an  Ada  program. 

Cer t 1 f i cat i on  of  Test  Correctness  Without  the  Feature.  I n 
developing  the  validation  tests  for  address  clauses  and 
interrupts,  1  assumed  that  the  Ada  compiler  being  studied 
correctly  implemented  all  other  language  constructs  used  in  the 
test.  As  each  test  was  developed  for  a  specific  use  of  Ada’s 
address  clause,  a  similar  version  that  did  not  make  use  of  the 
address  clause  (but  identical  in  every  other  way)  was  also 
developed,  compiled,  and  examined  for  syntax  errors. 

Performing  these  parallel  compilations  ensured  that  the 
validation  tests  developed  did  not  contain  illegal  uses  of 
other  Ada  constructs  that  could  affect  the  outcome  of  a 
validation  test. 

Combinations  Tested  Separately.  The  features  being 
studied,  address  clauses  and  interrupts,  often  could  be  used  in 
a  number  of  different  ways.  Because  compilers  are  free  to 
reject  the  use  of  a  feature  under  certain  conditions  (e.g.  , 
allowing  address  clauses  for  variables  but  not  for  constants) , 


one  test  was  written  for  each  use.  Writing  separate  tests  for 


combinations  of  the  feature’s  use  ensured  that  none  of  the 


tests  would  be  ruled  inapplicable  while  they  still  contained 
tests  for  uses  of  the  feature  that  a  compiler  claimed  to 
support.  Therefore,  a  compiler  would  be  tested  for  all  uses  of 
the  feature  that  it  claimed  to  implement.  Should  a  compiler 
fail  a  test,  the  specific  nature  of  the  test  would  also  help  to 
pinpoint  the  set  of  c i r cums tance s  that  caused  the  compiler  to 
fail. 

Eliminate  Implementation-Dependencies  in  Tests.  In  each 
test  design  I  used  only  those  constructs  (excepting  address 
classes  and  interrupts)  that  all  compilers  must  support.  For 
example,  all  compilers  have  to  support  a  data  type  named 
INTEGER  but  do  not  have  to  support  the  type  named 
SHORT_ I NTEGER ,  so  tests  that  required  integer  objects  were 
declared  using  the  INTEGER  type. 

Review  by  ACVC  Test  Developers.  Finally,  the  tests 
developed  in  this  thesis  were  reviewed  for  accuracy  and 
correctness  by  the  primary  ACVC  test  developers  for  the  Ada 
Validation  Facility.  These  developers  found  that  the 
validation  tests  developed  in  this  research  were  'on  target," 
the  approach  used  in  developing  the  tests  was  "sound,"  and  the 
use  of  ADDRESS_PACKAGE  to  solve  the  problem  of  non-portability 
of  address  clauses  agreed  with  the  developers’  solution  for 
this  problem  (Brashear,  1987b). 

The  design  techniques  and  software  reviews  built  in  to  the 
design  of  these  tests  ensure  that  the  test  suite  developed  for 
address  clauses  and  interrupts  will  detect  illegal 


pleir.er.taticns  of  these  features  and  certify  valid 


p 1 emer tat ; ons  of  these  features.  The  test  simplicity, 
r.:m:zat;or.  cf  error-prone  constructs,  and  parallel  testing 
th'ut  the  feature  preclude  the  Introduction  of  erroneous 
age  _f  Ada  constructs  that  are  not  being  tested. 

By  designing  the  test  suite  to  test  elementary  uses  of 
dress  c.auses  ar.d  interrupts,  I  have  designed  a  test  suite 
*•  a  te  applied  to  many  compilers  with  varying 
:  .  e  ~e  t  a  t  ;  :■  r.  s  cf  these  features.  This  testing  of  elementary 

-  ■  :  the  feature  avoids  more  complicated  combinations  of  the 

i  *  ■ .  r e  s  use  which  makes  the  test  more  portable.  The  review 

• r -  p r . ma r y  ACVC  test  developers  provides  the  assurance  that 
s  . .  *  e  similar  to  that  developed  in  this  thesis  would  be  used 
•  ■  A  '  V  7  *:  perform  actual  Ada  compiler  evaluations. 
7-e-ef:re  this  suite  may  be  used  to  answer  the  first 

-  .•  .  1  the  thesis  problem.  Developers  of  embedded 

;  .  ' a  *  .  .ns  before  they  use  a  compiler’s  address  clause  or 

•e-ru;*  feature  in  their  application,  may  apply  these 
.  d  a  •  :  :  tests  developed  in  this  thesis  to  their  compiler  and 

a  Ate t. ter  ’hat  compiler’s  implementation  is  valid,  and 
--’.fit  suitable  for  their  application. 

.  .  ut  Test  Results 

Because  of  the  varying  level  of  Chapter  13  implementations 
a*  the  LRM  allows,  discussed  in  chapter  4  of  this  thesis, 
me  validation  tests  for  Chapter  13  features  may  be 
applicable  for  certain  compilers.  The  only  way  for  a 
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compiler  to  fail  a  validation  is  for  it  to  fail  a  test  that  is 
applicable.  The  results  for  the  validation  tests  will  be 
reported  as  passed  (the  compiler  implemented  the  feature 
correctly),  failed  (the  compiler  did  not  implement  the  feature 
correctly) ,  or  inapplicable  (no  test  was  made) . 

Enumeration  Representation  Clauses.  The  primary  result 
obtained  from  this  set  of  tests  was  a  greater  understanding  of 
the  thesis  problem  of  validating  Chapter  13  features.  While 
compiler  A  passed  all  four  tests  that  were  written,  these  four 
tests  examined  only  four  of  the  13  test  objectives  for 
enumeration  representation  clauses.  No  determination  of  a 
language  feature’s  validity  of  implementation  may  be  made  on 
such  incomplete  testing,  because  a  compiler  must  pass  all 
applicable  tests  to  be  certified  as  a  valid  Ada  compiler.  In 
the  case  of  compiler  A,  all  test  objectives  were  applicable  to 
Its  implementation  of  enumeration  representation  clauses,  so 
all  tests  would  have  to  be  run  before  it  could  be  certified  as 
a  valid  Ada  compiler. 

Address  Clauses  and  Interrupts.  One  hundred  and  ten  tests 
were  written  to  test  the  18  objectives  for  address  clauses  and 
the  five  objectives  for  interrupts.  A  complete  list  of  the 
tests  run  on  the  compilers  and  of  the  results  of  those  tests  is 
provided  at  Appendix  D. 

Compiler  A  passed  58  tests,  failed  none,  and  was  not 
tested  on  52  because  they  were  inapplicable.  Compiler  B  passed 
63  tests,  failed  1,  and  was  not  tested  on  46  inapplicable 


tests.  Compiler  C  passed  58  tests,  failed  rone,  and  was  not 
tested  on  52  inapplicable  tests. 

The  test  that  compiler  B  failed,  test  BD5102A,  tests  the 
ACVC  I mp 1 emen t ers ’  Guide  objective:  “Check  that  an  address 
clause  cannot  be  given  for  a  (task)  entry  family'  (Goodenough, 
1986:56) .  This  is  a  class  B  test  that  should  fail  compilation 
because  it  includes  an  illegal  use  of  the  address  clause. 
Compiler  B,  however,  compiled  test  BD5102A  without  detecting 
the  error,  thus  failing  the  test.  After  discussing  this  failed 
test  with  the  compiler  developers,  the  error  that  caused 
compiler  B  to  fail  test  BD5102A  was  corrected.  Because  the 
later  version  passed  all  tests,  and  I  determined  that  the 
corrected  version  did  not  affect  the  benchmarks  developed  in 
this  thesis,  compiler  B  was  used  to  develop  and  run  the 
benchmarks  for  interrupt  delay  time  in  this  thesis. 

Using  the  guidelines  of  the  Ada  Validation  Facility 
(Wilson,  1987a) ,  compiler  A  and  compiler  C’s  implementations  of 
address  clauses  and  interrupts  would  be  ruled  valid  because 
they  passed  all  applicable  tests.  Compiler  B's  implementation 
originally  would  have  been  ruled  invalid  because  it  originally 
failed  test  BD5102A.  When  the  compiler  was  corrected  and  all 
applicable  tests  were  passed,  then  compiler  B’s  implementation 
would  be  ruled  valid  as  well. 

Certification  of  Performance  Evaluation  Tests 

This  section  will  answer  the  question:  how  do  we  know  that 
the  benchmarks  developed  in  this  thesis  for  interrupt  response 
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time  present  results  (or  even  study  the  problems)  of  interest 
to  the  embedded  applications  developers'7  This  question  will  be 
answered  by  reviewing  how  the  interrupts  feature  is  currently 
implemented  and  used,  then  expanding  upon  this  review  to 
identify  how  the  feature  could  alternatively  be  used.  I  will 
then  show  that  the  benchmarks  developed  to  measure  interrupt 
delay  time  for  interrupts  associated  with  task  entries  measure 
the  effects  of  the  various  uses  of  this  feature. 

Current  Use  of  Interrupts  Feature.  Because  compilers  that 
implement  address  clauses  for  task  entries  are  just  recently 
becoming  widely  used,  there  currently  does  not  exist  a  body  of 
documented  practical  experience  in  the  feature’s  use.  I  found, 
however,  through  personal  and  telephone  interviews  with  Ada 
compiler  and  application  researchers  and  developers  that  use  of 
task  entries  associated  with  interrupts  is  currently  being 
dictated  by  the  compiler’s  implementation  of  the  feature  or  by 
personal  choice  (Johnson,  1987) .  I  found  that  some  developers 
were  using  compilers  that  restricted  the  interrupt-handling 
task  to  be  a  single-entry  task.  Other  developers  were  using  a 
single-entry  task  to  handle  each  interrupt,  even  though  their 
compiler  did  not  place  this  restriction  on  the  feature’s  use. 

I  did  not  find,  however,  that  this  design  of  interrupt  handling 
tasks  was  based  on  an  informed  investigation  of  the  efficiency 
of  possible  alternatives.  These  alternatives  will  be  discussed 
be  low . 

Alternative  Use  of  Interrupts  Feature.  The  semantics  of 
Ada  tasking  present  a  number  of  alternative  methods  for 


associating  any  number  of  interrupts  with  task  entries  using  an 
address  clause.  One  may  wish  to  handle  all  of  the  possible 
interrupts  in  an  application  or  just  a  subset  (even  of  size 
one) .  Assume,  for  example,  a  developer  wishes  to  handle  four 
of  16  possible  interrupts  in  his  application.  Although  there 
are  others,  three  possible  designs  for  the  tasks  are:  (1) 
declare  one  task  with  four  entries,  each  associated  with  one  of 
the  interrupts;  (2)  declare  two  tasks  with  two  entries  per 
task;  or  (3)  declare  four  tasks  with  one  entry  per  task.  The 
three  major  considerations,  then,  in  the  design  of  interrupt 
handling  task  (s)  ,  defined  by  the  syntax  of  Ada  and  the 
configuration  of  the  target,  are:  (1)  the  number  of  interrupts 
to  be  handled;  (2)  the  number  of  tasks  to  handle  the 
interrupts;  and  (3)  the  number  of  entries  per  task. 

The  benchmarks  developed  in  this  thesis  form  a 
representative  sample  of  the  various  techniques  for  associating 
tasks  with  interrupt.  Recall  from  Table  1  in  chapter  4  that 
INTJTEST1,  I NT_TEST2 ,  I NT_TEST3 ,  and  I NT_TEST4  are  all  designed 
to  handle  a  high  number  of  interrupts  (10)  on  the 
MI  L-STD- 1750A ’ s  16  possible  interrupts  (DoD,  1982:19),  with 
designs  ranging  from  10  tasks  with  one  entry  each  to  one  task 
with  10  entries.  These  benchmarks  produce  a  comparative 
measure  of  interrupt  delay  time  for  the  interrupts  feature  as 
it  is  currently  being  used,  and  as  it  could  be  used.  INT_TEST5 
and  INT_TEST6  test  the  task  entry  mix  with  a  medium  (three) 
number  of  interrupts  being  handled.  INT_TEST7  provides  the 
baseline,  handling  one  interrupt  with  one  single-entry  task. 


By  measuring  the  interrupt  delay  time  for  this  feature  as  it  is 
currently  being  used  as  well  as  for  other  possible  uses,  the 
benchmarks  provide  the  answer  to  the  question:  'How  efficient 

is  this  feature’s  (address  clauses  for  interrupts) 
implementation’ ' 

The  reader  might  ask,  'Does  it  make  sense  to  write  one 
task  to  handle  a  number  of  interrupts?’  The  answer  is  ’yes,' 
because  interrupts  are  often  related,  and  the  interrupt¬ 
handling  functions  are  similar.  For  example,  if  the  operations 
one  might  perform  to  handle  a  floating  point  overflow  and  a 
fixed  point  overflow  are  similar,  it  would  be  logical  to 
localize  these  operations  in  one  interrupt  handling  block. 

The  results  from  these  seven  benchmarks  demonstrate  how 
they  provide  comparative  information  on  the  efficiency  of  the 
compiler.  Not  only  do  they  indicate  whether  the  interrupts 
feature  is  efficient  enough  for  a  particular  application,  they 
also  indicate  the  most  efficient  way  to  use  this  feature. 

Some  developers  were  not  using  Ada’s  interrupts  feature 
because  they  said  it  was  more  efficient  to  handle  interrupts  in 
the  run-time  executive  or  operating  system.  Others  were  using 
the  feature  in  only  one  way  (one  singe-entry  task  for  each 
interrupt  being  handled)  and  had  not  investigated  other 
approaches.  If  the  embedded  systems  developer  is  to  write  an 
application  that  will  execute  as  efficiently  as  possible,  he 
must  know  the  most  efficient  way  to  use  a  particular  feature 
for  his  comp i 1 er / tar ge t  combination.  The  benchmarks  for 
interrupt  delay  time  provide  these  measures  of  efficiency  for 


the  interrupts  feature  as  it  may  be  used  in  an  application. 

The  benchmarks  will  either  provide  additional  support  for  the 
single  task/multiple  entry  method  of  interrupt  handling  in  an 
application  or  prove  it  lacking  and  provide  the  embedded 
applications  developers  the  impetus  to  use  alternative,  more 
efficient,  designs  for  interrupt  handling. 

Performance  Evaluation  Test  Results 

This  section  will  report  the  results  of  the  benchmarks 
developed  in  this  thesis.  The  benchmarks  were  compiled  with 
only  compiler  B  and  run  on  the  Sperry  1631  MIL-STD- 1750A 
computer  because  B  was  the  only  compiler  available  during  my 
research  that  implemented  the  interrupts  feature.  The  results 
reported  here,  therefore,  will  not  be  used  to  compare  the 
relative  efficiency  of  one  compiler  to  another.  The  results  do 
indicate  that  these  benchmarks  may  be  applied  to  compilers 
supporting  address  clauses  for  interrupts  to  determine  the  most 
efficient  use  of  the  feature. 

Enumeration  Representation  Clauses.  Test  A13_3_3C, 
designed  to  measure  the  effect  of  performing  a  successor 
operation  on  an  enumeration  object  given  an  alternate 
representation,  was  run  on  one  se 1 f - tar ge 1 1 ng  compiler, 
compiler  A.  The  result  from  this  benchmark  was  a  negative  mean 
(test  loop  time  -  control  loop  time)  and  a  large  standard 
deviation.  These  results,  skewed  by  the  effect  of  the 
operating  system  on  the  benchmark,  reinforced  the  need  to  avoid 
these  distortions  as  discussed  in  Chapter  3. 


Test 

Name 

Mean 

(seconds ) 

Standard 
Deviation 
(seconds ) 

Elapsed 

Time 

(seconds ) 

I  NT_ 

TEST  1 

7 . 365 

E-4 

7.441 

E-6 

3.819  E-l 

I  NT 

TEST2 

7.731 

E-4 

7 . 020 

E-6 

4 . 497  E- 1 

I  NT_ 

TEST3 

7 . 958 

E-4 

7.691 

E-6 

5 . 240  E- 1 

I  NT_ 

TEST4 

7 . 906 

E-4 

5.914 

E-6 

6.360  E-l 

I  NT 

TEST5 

7 . 395 

E-4 

7.641 

E-6 

3 . 799  E- 1 

I  NT_ 

TEST6 

7 . 585 

E-4 

6.314 

E-6 

4 . 708  E- 1 

I  NT_ 

TEST7 

7.341 

E-4 

6 . 965 

E-6 

3.810  E-l 

Assuming  that  the  interrupt  delay  times  are  normally 
distributed,  I  used  a  two-sample  t  test  and  a  level  of 
significance  of  0.01  to  find  that  the  mean  interrupt  delay  time 
for  I NT_TEST 1  was  less  than  that  for  I NT_TEST2 ,  I NT_TEST3 ,  or 
INT_TEST4  (Larsen  and  Marx,  1986:364) .  Likewise,  I  found  that 
the  mean  interrupt  delay  time  for  INT_TEST5  was  less  than  that 
for  INT_TEST6.  The  calculations  for  the  two-sample  t  test  are 
found  in  Appendix  Q. 

These  results  show  that  the  design  of  the  interrupt 
handling  tasks  does  have  an  effect  on  the  interrupt 
delay  time.  Whether  the  benchmark  is  handling  a  high  (10)  or 
medium  (3)  number  of  interrupts,  the  most  efficient  approach  in 
terms  of  minimum  interrupt  delay  time  and  tasking  overhead  (as 
measured  by  the  elapsed  time  of  the  benchmark)  is  to  write  a 
single  entry  task  for  each  interrupt  being  handled  in  the 
application.  This  does  not  mean,  however,  that  the  single¬ 
entry  task  approach  will  be  the  most  efficient  for  all 
comp i 1 er / tar ge t  combinations.  These  benchmarks  may  be  applied 
to  other  compilers  to  determine  the  most  efficient  approach  for 
particular  applications. 

Summary 

This  chapter  presented  a  certification  of  the  validation 
and  performance  evaluation  tests  developed  in  this  thesis,  and 
reported  the  results  of  those  tests  on  three  validated  Ada 
compilers.  Validation  test  design  techniques  and  a  design 


review  were  described  to  certify  that  the  validation  tests  will 


determine  the  validity  of  a  compiler’s  implementation  of  Ada’s 
address  clauses  and  interrupts  features.  The  benchmarks  were 
certified  by  showing  that  they  measured  interrupt  delay  time 
for  the  interrupts  feature  as  it  is  currently  used  and  as  it 
could  be  used . 

The  results  of  the  validation  tests  for  three  compilers, 
in  which  one  compiler  initially  failed  (and  then  later  passed) 
one  test,  were  detailed.  This  reinforced  the  idea  that  a 
validated  Ada  compiler  may  not  Implement  all  of  the  untested 
features  correctly.  Finally,  the  results  of  the  benchmarks 
compiled  with  compiler  B  and  executed  on  a  Sperry  1631 
MIL-STD- 1750A  processor  were  presented,  showing  the  single¬ 
entry  task  approach  for  the  design  of  interrupt  handling  tasks 
to  be  the  most  efficient  approach  for  the  comp  1 1 er / tar ge t 
studied . 

The  next  chapter  reviews  how  well  the  work  in  this  thesis 
solved  the  thesis  problem,  draws  conclusions  about  this 
research,  and  lists  recommendations  for  future  study. 


VI  .  Conclusions  and  Recommendations 


This  chapter  summarizes  how  the  approach  used  and  software 
developed  in  this  research  answered  the  questions  posed  in  the 
thesis  problem,  presents  conclusions  about  this  research,  and 
outlines  areas  for  future  research. 

The  Problem  Revisited 

Recall  from  Chapter  1  that  there  were  two  questions  to  be 
answered  by  potential  users  of  Chapter  13  features  before  these 
features  were  used  in  embedded  applications:  (1)  does  the 

compiler's  implementation  of  the  feature  conform  to  the 
definition  of  that  feature  in  the  LRM  and  (2)  is  the 
implementation  of  the  feature  efficient  enough  for  the  users’ 
application7  The  first  half  of  the  thesis  problem,  concerning 
the  validity  of  the  implementation  of  address  clauses  and 
interrupts  was  solved  by  the  validation  tests  written  for  those 
features.  The  design  techniques  used  in  the  development  of 
these  tests,  as  discussed  in  Chapter  5,  ensure  a  complete, 
accurate,  and  error-free  test  suite  for  Address  Clauses  and 
Interrupts . 

The  second  part  of  the  thesis  problem,  the  efficiency  of 
the  feature,  was  more  difficult  to  define  and  quantify  so  that 
it  could  be  tested.  At  the  outset,  the  two  metrics  used  most 
often  to  quantify  'efficiency'  were  time  (execution  speed)  and 
space  (amount  of  memory  used)  .  As  the  research  progressed  , 
time  became  the  primary  metric  because  of  advances  in  the 
memory  capability  of  the  MI L - STD  -  1 750A  processor. 


I  was  able  to  determine,  through  numerous  interviews,  how 
the  interrupts  feature  was  being  used  by  embedded  systems 
applications  researchers  and  developers.  From  this  I  designed 
a  suite  of  benchmarks  and  support  software  that  measured  the 
efficiency  of  the  feature  as  it  was  currently  used  as  well  as 
alternative  uses  allowed  by  the  syntax  of  the  features 
specified  in  the  LRM.  These  benchmarks,  then,  answer  the 
second  half  of  the  question  in  the  thesis  problem. 

Therefore,  this  thesis  shows  that  the  problem  can  be 
solved  and  demonstrates  this  fact  by  answering  the  validity  and 
efficiency  questions  for  address  clauses  and  interrupts. 

Conclusions 

At  the  beginning  of  this  thesis  project,  I  felt  that  the 
emphasis  of  the  research  should  be  on  benchmarking  Chapter  13 
features,  and  that  validation  of  those  features  was  a  necessary 
(but  not  very  difficult)  step  on  the  way  to  that  goal.  As  the 
research  progressed,  it  became  increasingly  apparent  that 
validation  and  performance  evaluation  were  complementary 
disciplines  of  equal  importance.  Before  Ada  researchers 
measure  a  compiler’s  efficiency  with  benchmarks,  they  must  know 
that  the  feature  or  construct  being  studied  is  correctly 
implemented.  If  compiler  validation  is  not  performed, 
non-valid  implementations  may  appear  to  be  more  efficient  when 
benchmarked  because  these  implementations  may  not  provide  all 
the  capability  of  a  valid  implementation. 


The  approach  used  in  this  thesis  project  to  determine  the 
validity  and  efficiency  of  compilers’  implementations  of 
address  clauses  and  interrupts  may  be  applied  to  other 
features.  This  application  assumes,  however,  that  researchers 
and  developers  can  identify  the  features  to  be  tested  and  how 
to  test  them.  The  difficulty  of  this  research  is  not  so  much 
in  the  design  of  validation  tests  and  benchmarks,  but  in 
determining  what  to  test,  why  to  test  it,  and  how  to  write  a 
valid  test.  I  was  able  to  prioritize  the  Chapter  13  features 
for  study  by  interviewing  Ada  researchers  and  developers  to 
determine  what  features  were  most  important  to  their 
applications.  I  mistakenly  assumed  that  there  would  be  a 
strong  consensus  among  embedded  application  developers 
concerning  what  was  "most  important'  in  Chapter  13.  The 
reality  was  (and  is)  that  compiler  implementations  are  being 
improved  just  as  new  embedded  applications  problems  are  being 
solved.  No  one  has  a  list  of  exactly  what  the  'problems  of 
embedded  applications’  are.  Although  there  is  some  overlap, 
each  developer  has  his  own  set  of  problems,  often  unique  to  his 
app 1 l ca  t i on . 

Just  as  there  are  varying  levels  of  Ada's  use  in 
developing  embedded  applications,  so  too  are  there  varying 
levels  of  interest  in  the  Chapter  13  features.  Some  developers 
interviewed  in  this  research  said  that  they  did  not  plan  to  use 
any  Chapter  13  features,  because  they  felt  that  the  same 
functions  could  be  performed  more  efficiently  with  assembly 
language,  JOVIAL,  or  other  languages  for  embedded 


applications.  DoD  Directive  3405.1,  which  mandates  the  use  of 
Ada  in  new  applications,  should  increase  the  interest  in  how  to 
test  the  validity  and  efficiency  of  Chapter  13  features. 
Embedded  applications  developers  will  either  use  Ada  or  request 
a  waiver  because  the  current  technology  cannot  solve  their 
problem  (DoD,  1987) .  In  either  case,  these  developers  will 
have  to  find  objective  answers  to  questions  concerning  the 
validity  and  efficiency  of  Ada  compilers,  with  emphasis  on  the 
Chapter  13  features  that  are  so  vital  to  the  success  of 
embedded  applications.  Whether  Ada  is  or  is  not  used  for 
developing  new  embedded  applications,  the  decision  will  have  to 
be  an  infor me d  one. 

Validation  and  performance  evaluation  tests  also  generate 
a  positive  result  that  is  not  part  of  their  design,  but  is  a 
by-product  of  their  existence.  This  result  is  the  cause-effect 
relationship  one  researcher  found  between  the  release  of 
compiler  benchmarks  for  Ada  language  constructs  and  efficient, 
complete  implementations  of  those  constructs  in  compilers 
released  after  the  wide  distribution  of  those  benchmarks.  This 
heightened  cross-flow  of  information  concerning  efficiency, 
validity,  and  shortcomings  of  various  compiler  implementations 
will  increase  the  pool  of  knowledge  about  those 

l mp 1 emen ta t 1 ons ,  increase  competition  between  compiler  vendors, 
and  result  in  improved  development  tools  for  those  using  Ada 
for  embedded  applications. 

There  has  been  some  discussion  that  the  distribution  of 
the  Ada  Compiler  Evaluation  Capability  (ACEC)  ,  described  in 


? h a f  '.er 


may  be  limited  because  of  concerns  about  misuse  of 


the  A"EC  to  label  compilers  as  ’good'  or  "bad"  with  respect  to 
or.e  construct  or  feature.  Although  the  misuse  of  any 
evaluation  tool  is  possible,  the  potential  for  increase  in  the 
}ua.;ty  cf  implementations  of  Ada  compilers,  I  feel,  outweighs 
*  1  -  ree^  * c  prevent  misuse  of  the  ACEC  test  suite.  The  AJPO 
zhiu.d  release  the  ACEC  to  widest  possible  distribution, 
perhaps  placing  it  on  the  Ada  Software  Repository,  in  a  fashion 
s  .  m  .  .  a  r  t:  that  used  for  the  SIGAda  PIWG  benchmarks,  and 
encourage  its  proper  use  with  an  aggressive  education  program. 

One  of  the  goals  of  this  thesis  project  was  to  develop 
benchmarks  that  could  be  applied  to  any  Ada  compiler  targeted 
to  the  MI L - STD-  1 750A  processor.  As  the  research  progressed,  it 
became  apparent  that  the  implementation-defined  features  of 
each  compiler  used  m  these  benchmarks  made  it  difficult  to  run 
the  benchmarks  on  another  comp  1 1 er / tar ge t  combination.  Just 
because  an  embedded  application  is  developed  in  Ada  does  not 
necessarily  mean  that  the  application  is  portable  without 
modification.  Because  certain  features  and  constructs  used  in 
the  application  must  be  tailored  to  the  underlying  hardware, 
some  redesign  and  modification  may  be  necessary  to  re-host  the 
application  on  another  processor.  The  software  engineering 
concepts  that  Ada  enforces,  (i.e.  data  typing,  constraint 
checking,  etc.)  will  make  this  process  easier  than  it  would  be 
with  an  application  developed  in  assembly  language,  because 
only  the  Chapter  13  features  will  have  to  be  modified  for  the 
application  to  be  run  on  the  new  processor. 


Recommendations  for  Future  Research 

Although  Ada  compilers  currently  do  not  have  to  implement 
all  of  the  features  in  Chapter  13,  a  complete  validation  test 
suite  for  those  features  would  further  stimulate  development  of 
implementations  of  Chapter  13  features.  The  goal  of  a  future 
research  project  would  be  to  complete  the  AC VC  test  suite  for 
Chapter  13  of  the  LRM.  The  current  test  design  objectives  of 
the  ACVC  Implementers ’  Guide  may  have  to  be  extended  to  allow 
the  tests  to  check  memory  locations,  word  length,  data 
alignment,  etc. ,  using  tools  other  than  test  software  written 
in  Ada.  Having  the  compiler  check  one  feature,  such  as  an 
address  clause,  by  using  another  feature,  such  as  the  ’ADDRESS 
attribute,  is  not  the  best  way  to  validate  compiler  features. 

If  a  compiler  vendor  is  going  to  do  a  poor  job  implementing  a 
feature,  or  do  something  that  is  not  expected  or  illegal,  one 
would  assume  that  he  would  be  smart  enough  to  avoid 
inconsistency  in  his  implementation  by  implementing  a 
complementary  construct  (in  this  case  the  ’ADDRESS  attribute) 
in  a  similar  fashion.  For  example,  if  one  uses  an  address 
clause  to  store  an  object  at  location  500,  but  the 
implementation  actually  stores  the  object  somewhere  else,  the 
compiler  implementer  may  implement  the  'ADDRESS  attribute  to 
return  500  when  it  is  applied  to  the  object  in  question, 
indicating  that  the  implementation  of  address  clauses  was 
valid.  This  future  research  would  develop  alternatives  to 
using  one  compiler  construct  to  determine  the  validity  of 


another . 


Another  research  topic,  determining  the  areas  of  weakness 
of  the  ACVC ,  may  require  the  efforts  of  many  researchers .  Some 
have  argued  that  by  allowing  compiler  vendors  to  know  the  exact 
structure  of  the  ACVC  test  suite,  minimal  implementations  may 
be  designed  to  pass  the  specific  tests.  This  future  research 
project  would  seek  out  the  holes  in  the  ACVC,  and  develop  tests 
to  fill  those  holes.  The  project  would  determine  whether  or 
not  an  implementation  that  does  not  comply  with  all  of  the 
spec i f i cat i ons  in  the  LRM  could  possibly  pass  the  validation 
test  suite.  In  short,  it  would  validate  the  validation  test 
suite.  Some  may  argue  that  developing  validation  tests  for  a 
validation  test  suite  could  be  recursively  applied 
indefinitely.  Although  a  validation  review  of  the  ACVC  test 
suite  could  not  be  proven  complete  and  valid  itself,  it  has  the 
potential  to  uncover  and  correct  errors  and  incompleteness  in 
the  ACVC  test  suite.  The  Importance  of  the  ACVC  test  suite  to 
the  development  of  Ada  compiler  technology  makes  this  project 
well  worth  the  effort. 


Appendix  A:  Validation  Test  Objectives 


This  appendix  contains  the  test  objectives  for  the  Chapter 
13  validation  tests  developed  in  this  thesis.  All  of  the 
information  in  this  Appendix  is  taken  from  the  A CVC 
Implementers ’  Guide  (Goodenough,  1986:Ch  13,  39-40,  53-56) . 


Enumeration  Representation  Clause  Test  Objectives 


Tl.  Check  that  a  record  representation  clause  cannot  be  given 
for: 

an  expanded  name  that  denotes  a  record  type; 
a  name  declared  by  an  object  declaration; 
a  name  declared  by  a  subtype  declaration; 
a  type  declared  by  a  private  type  declaration  prior 
to  the  full  declaration  of  the  type; 

an  incomplete  type  prior  to  the  full  declaration  of 
the  type  ; 

a  type  having  a  subcomponent  of  an  incompletely 
declared  private  type,  prior  to  the  complete 
declaration  of  the  composite  type; 
a  type  that  is  not  an  enumeration  type 

Implementation  Guideline:  In  each  case,  use  a  clause  that,  if 
possible,  would  be  allowed  for  the  actual  type  or  for  the 
completely  declared  type. 

T2 .  Check  that  two  enumeration  representation  clauses  cannot 
be  given  for  the  same  type. 

Implementation  Guideline:  The  two  clauses  should  specify 
identical  representations. 

T3 .  Check  that  an  enumeration  representation  clause  cannot  be 
given: 

in  a  package  specification  for  a  type  declared  in  an 
inner  package  specification; 

in  a  package  or  task  specification,  for  a  type 
declared  in  an  enclosing  package  specification  or 
declarative  part; 

in  a  package  body  for  a  type  declared  in  the 
corresponding  package  specification; 

after  the  occurrence  of  a  body  in  a  declarative  part. 


T4 .  Check  that  an  enumeration  representation  clause  cannot  be 
given  after  a  forcing  occurrence  for  the  type. 


T5 .  Check  that  if  an  enumeration  representation  clause  can  be 
given,  it  can  be  given  after  an  occurrence  of  the  type  name  in 
an  expression  of  a  pragma. 

T6 .  Check  that  the  name  of  the  enumeration  type  (or  a  subtype 
of  the  enumeration  type)  cannot  appear  as  a  choice  in  the 
aggregate  or  in  one  of  the  expressions. 

Implementation  Guideline:  The  name  should  be  used  in  an 
attribute  (e.g.  ,  ’VAL)  that  delivers  a  value  of  the  required 
type  . 

Til.  Check  that  an  enumeration  representation  clause  cannot  be 
given  for  a  derived  enumeration  type  if  the  derived  type 
definition  imposes  a  constraint  of  if  the  parent  type  has 
derivable  subprograms. 

Implementation  Guideline:  Write  separate  tests  for  these  two 
cases . 

T12.  Check  that  integer  codes  must  be  given  for  each 
enumeration  literal  of  the  type. 

Implementation  Guideline:  Check  that  neither  too  many  nor  too 
few  codes  ce :  be  given. 

Check  that  nonstatic  integer  codes  are  not  allowed. 
Implementation  Guideline:  Use  nonstatic  un i versa  1 _i n teger 

express  ions. 

Check  that  a  choice  cannot  be  nonstatic. 

T13.  Check  that  the  same  integer  code  cannot  be  given  for  two 
enumeration  literals. 

Check  that  the  Integer  codes  must  obey  the  predefined  ordering 
relation  for  the  type. 

Implementation  Guideline:  Include  some  aggregates  in  which 

choices  do  not  appear  in  the  order  defined  for  the  type,  and 
for  which  an  ordering  operator  has  been  explicitly  declared. 
Check  that  a  choice  in  the  aggregate  must  be  a  value  of  the 
enumeration  type. 

T14.  Check  whether  an  enumeration  representation  clause  can  be 
given  for  an  enumeration  type.  If  so,  check  that  such  types 
can  be  used  correctly  in  ordering  relations,  in  indexing 
arrays,  in  attributes,  and  in  generic  instantiations. 
Implementation  Guideline:  Include  cases  where  the  integer  codes 
have  negative  values  and  in  which  they  do  not  have  consecutive 
values . 

Implementation  Guideline:  Combine  this  check  with  various 
forms  of  aggregate:  all  choices  named  (when  some  enumeration 
literals  are  character  literals);  no  choices  named. 

Check  that  an  enumeration  representation  clause  can  be  given  in 
the  visible  or  private  part  of  a  package  for  a  type  declared  in 
the  visible  part. 

I mplementat ion  Guideline:  Repeat  the  checks  for  enumeration 
representation  clauses  given  in  a  generic  unit. 


T15.  Repeat  T14  for  a  derived  enumeration  type,  including  when 
the  parent  type  has  an  enumeration  representation  clause  given. 

T21.  Check  that  the  aggregate  in  an  enumeration  representation 
clause  cannot  be  considered  ambiguous. 

Implementation  Guideline :  Declare  more  than  one  one¬ 
dimensional  array  type  that  has  the  enumeration  type  as  its 
index  subtype . 

T22 .  Check  whether  an  enumeration  representation  clause  can  be 
given  for  a  type  derived  from  a  type  declared  in  a  generic 
instantiation . 


Address  Clause  Test  Objectives 

Tl.  Check  that  the  expression  in  an  address  clause  must  have 
the  type  SYSTEM. ADDRESS . 

T2 .  Check  that  an  address  clause  is  illegal  if  a  with  clause 
naming  the  predefined  package  SYSTEM  does  not  apply  to  the  unit 
containing  the  address  clause. 

Implementation  Guideline:  Check  for  objects,  subprograms, 
packages,  tasks,  and  entries. 

T3 .  Check  that  if  an  address  clause  is  allowed,  a  with  clause 
naming  SYSTEM  need  not  be  given  for  the  compilation  unit 
containing  the  address  clause  as  long  as  such  a  clause  applies 
to  the  unit. 

Implementation  Guideline:  Check  for  address  clauses  in  package 
bodies,  subprogram  bodies,  and  subunits.  Include  a  check  for 
generic  unit  bodies  and  subunits. 

T4 .  Check  that  an  address  clause  cannot  be  given  for  a  named 
number,  an  exception,  a  formal  parameter  of  a  subprogram, 
entry,  or  generic  unit,  a  generic  formal  object,  a  generic 
subprogram,  a  generic  package,  a  loop  parameter,  an  object 
designated  by  an  access  value,  a  slice,  or  a  component  of  an 
object  . 

Check  that  an  address  clause  cannot  be  given  for  a  library  unit 
or  a  generic  unit. 

T5.  Check  that  an  address  clause  cannot  be  given  for  an 
expanded  name  or  for  a  name  declared  by  a  renaming  declaration. 
Implementation  Guideline:  Include  renamings  of  objects, 
subprograms,  packages,  tasks,  and  entries. 

T6.  Check  that  an  address  clause  cannot  be  given: 

in  a  package  specification  for  an  object,  a  package, 
etc.,  declared  in  an  inner  package  specification; 
in  a  package  or  task  specification,  for  an  object, 


a  package,  etc.  ,  declared  in  an  enclosing  package 
specification  or  a  declarative  part; 
in  a  package  body  for  an  object,  package,  etc. 
declared  in  the  corresponding  package  spec i f i cat  1  on ; 
after  the  occurrence  of  a  body  in  a  declarative  part. 
I mpl ementat ion  Guideline:  In  particular,  check  for  a 
subprogram  body  that  also  acts  as  the  declaration  of 
the  subprogram. 

T7 .  Check  that  an  address  clause  cannot  be  given  for 
subprogram  if  more  than  one  subprogram  with  the  same  name  is 
declared  explicitly  in  the  same  package  specification  or 
declarative  part. 

Implementation  Guideline:  Include  a  generic  instantiation  and 

a  renaming  declaration  as  well  as  a  subprogram  declaration. 
Check  that  if  an  address  clause  can  be  given  for  a  subprogram, 
it  can  be  given  when  the  subprogram  is  overloaded  by: 

a  subprogram  declared  in  an  outer  declarative  region 
or  library  package, 

an  entry  declaration  (when  the  subprogram  is  declared 
in  the  task  body)  , 

an  implicitly  declared  derived  subprogram. 

T8 .  Check  that  the  expression  in  an  address  clause  must  be  a 
simple  expression. 

Til.  Check  whether  an  address  clause  can  be  given  for  an  object 
declared  in  a  declarative  part. 

Implementation  Guideline:  Use  a  variable  and  constant  having 
the  following  types:  enumeration,  Integer,  floating  point, 
fixed  point,  array,  record,  access,  private,  limited  private, 
and  task . 

Implementation  Guideline:  Include  a  check  for  declarative 

parts  of  subprograms,  blocks,  and  package  bodies. 

T12.  Repeat  Til  for  generic  units. 

T13.  Check  whether  an  address  clause  can  be  given  for  an  object 
declared  in  a  package  specification. 

Implementation  Guideline:  Use  a  variable  and  a  constant  having 
the  following  type:  enumeration,  integer,  floating  point,  fixed 
point,  array,  record,  access,  private,  limited  private,  and 
task  . 

Implementation  Guideline:  Include  a  check  that  the  address 
clause  can  be  given  in  the  private  part  for  an  object  declared 
in  the  visible  part. 

T14.  Repeat  T13  for  generic  packages. 

T21.  Check  whether  an  address  clause  can  be  given  for  a 
subprogram  declared  in  a  declarative  part  by  a  subprogram 
declaration  or  a  generic  instantiation. 


Implementation  Guideline:  Check  for  a  declarative  part  of  a 
block,  a  package  body,  a  subprogram,  and  a  task  body. 


T22 .  Check  whether  an  address  clause  can  be  given  for  a 
subprogram  declared  in  a  package  a  subprogram  declaration  or  a 
generic  Instantiation. 

Implementation  Guideline:  Include  a  check  that  the  clause  can 

be  given  in  the  private  part  for  a  subprogram  declared  in  the 
visible  part. 

T31.  Check  whether  an  address  clause  can  be  given  for  a  package 
declared  in  a  declarative  part  by  a  package  declaration  or  a 
generic  instantiation. 

Implementation  Guideline:  Check  for  a  declarative  part  of  a 
block,  package  body,  subprogram,  and  task  body. 

T32 .  Check  whether  an  address  clause  can  be  given  for  a  package 
declared  in  a  package  by  a  package  declaration  or  generic 
instantiation . 

Implementation  Guideline:  Include  a  check  that  the  clause  can 

be  g  iven  on  the  private  part  for  package  declared  in  the 
visible  part . 

T41.  Check  whether  an  address  clause  can  be  given  for  a  task 
type  or  a  single  task  declared  in  a  declarative  part. 
Implementation  Guideline:  Check  for  a  declarative  part  of  a 

block,  a  package  body,  a  subprogram,  and  a  task  body. 

T42.  Check  whether  an  address  clause  can  be  given  for  a  task 
type  or  a  single  task  declared  in  a  package 

Implementation  Guideline:  Include  a  check  that  the  clause  can 

be  given  in  the  private  part  for  a  task  or  a  task  type  declared 
in  the  visible  part. 


Interrupts  Test  Objectives 

Tl.  Check  that  an  address  clause  cannot  be  specified  for  an 
entry  that  has  a  parameter  of  mode  out  or  mode  in  out. 

T2 .  Check  that  an  address  clause  cannot  be  specified  for  an 
entry  f  ami  1 y . 

T3 .  Check  that  the  name  in  an  address  clause  for  an  entry 
cannot  be  an  expanded  name . 

T4.  Check  that  an  address  clause  for  an  entry  cannot  be  given 
within  the  declarative  part  of  the  task  body. 

Til.  Check  that  if  an  implementation  supports  address  clauses 
for  entries,  such  a  clause  can  be  given  for  an  entry  of  a  task 
type  as  well  as  for  an  entry  of  a  single  task. 


endix  B:  Validation  Tost  Soft wa r e 


This  Appendix  contains  a  sample  of  the  validation  tests 
developed  in  this  thesis.  A  machine  readable  version  of  the 
soft  wa  re  is  available  from  the  Air  Force  Institute  of  Technology 
Department  of  Mathematics  and  Computer  Science  (ENC) ,  WPAFB  OH 
45433  . 

Validation  Test  Naming  Convention 

The  name  associated  with  the  validation  tests  conforms  to 
the  naming  convention  for  the  tests  in  the  ACVC  test  suite.  The 
test  names  will  be  of  the  form  NAME. ADA,  with  NAME  containing  up 
to  nine  characters  defined  below: 


Character  Position 


DescriDtion 


1  Class  of  test  ( A , B , C , D , E , L ) 

2  AIG  chapter  number  (Hex) 

3  AIG  section  number  (Hex) 

4  AIG  subsection  number  or 

letter 

5,6  AIG  test  objective  number 

7  Test  sequence  letter  (A-Z) 

8  Compilation  sequence  digit 

(0-9)  (Not  required) 

9  ‘M‘  indicates  main  program 

(for  several  compilation 
units)  (Wilson,  1987b). 

By  my  using  this  convention,  the  tests  are  more  likely  to  be 
understood  and  accepted  by  those  familiar  with  the  conventions 
of  the  ACVC  test  suite.  This  convention  thus  helps  to  satisfy 
the  requirement  that  the  tests  clearly  identify  their 
objectives.  The  name  of  the  test  does  this  by  referring  to  the 
test  objectives  in  the  ACVC  Impl ementers ’  Guide  (Goodenough , 
1986)  and  Appendix  A  to  this  thesis. 


Enumeration  Representation  Clauses  Test  Names 


BD3001A. ADA 
BD3002A. ADA 
BD3004A. ADA 
BD3012A. ADA 


lV 


Enu meration  Representation  Clauses  Sample  Test: 


--  BD3012A 

■-  Check  that  integer  codes  must  be  given  for  each  enumeration 

--  literal  of  the  type 

-  -  Check  that  nonstatic  integer  codes  are  not  alio  we  d  (in 
--  giving  integer  codes  to  each  enumeration  literal  of  the 

-  -  t  y  p  e  ' 

-  -  A  u  t  h : r :  C  a  p  t  Dan  Joyce 

-  -  Vers : : n •  1.1 

--Date  :  J un  8  7 


procedure  BL3012A(one  :string; 

two:  string; 

three:  string; 

four:  string; 

five:  string)  is 

type  enum_type  is  ( a  1  , a2 , a3 . a4 , a5 )  ; 
type  enurr._typel  is  (al  ,a2  ,a3  ,a4  ,a5)  ; 
type  e.num_type2  is  ( a  1  ,  a2  ,  a3  ,  a4  ,  a5  )  ; 

for  e:,n.T._  type  use  (1,2, 3, 4);  --  Illegal,  too  few 

--  Integer  codes 

for  er.um_  type  1  use  (  1  ,  2 , 3 , 4 , 5 , 6  )  ;  --  Illegal,  too  many 

--  integer  codes 

for  enum_type2  use  (one ’ length , two ’ length , three ’ length , 

f our ’ 1  eng th , f i ve ’ 1  eng th )  ; 

--  Illegal  use  of  nonstatic 
--  Universal  integer  for  Choices 

begin 

null; 

end  BD3012A; 


Address  Clause  and  Interrupts  Test  Names: 


BD500 1  A . ADA 

BD5002A . ADA 
BD5002E . ADA 

AD5003A . ADA 
AD5003E . ADA 


BD5002B . ADA 

AD5003B . ADA 


BD5002C . ADA 

AD5003C . ADA 


BD5002D . ADA 

AD5003D . ADA 


BD5004A. ADA 


BD5004B . ADA 


BD5004C . ADA 


BD5005A . ADA 

BD5006A. ADA 
BD5006E . ADA 

AD5007A . ADA 

BD5008A . ADA 

AD50 1 1  A . ADA 
AD5  0 1  IE . ADA 
AD50 111. ADA 
A  D  5  0 1 1M. ADA 
AD50 1  IQ . ADA 

AD  5  0  1 2  A . ADA 
AD5  0 1 2  E . ADA 
AD  5  0  121  . ADA 
AD5  0 1 2  M . ADA 
AD5  0 12Q ■ ADA 

AD5013A. ADA 
AD50 13E . ADA 
AD5013I . ADA 
AD 50 1 3 M . ADA 
AD5013Q. ADA 

AD5014A. ADA 
AD 50 1 4E . ADA 
AD5014I . ADA 
AD5014M. ADA 
AD50 14Q . ADA 


ADS  0  2 1  A . ADA 


AD5C31A. ADA 


AD504  1  A. ADA 


BD5101A. ADA 


BD5 1 0  2 A . ADA 


BD5103A. ADA 


BD5 1 04 A . ADA 


AD5 1 1 1A. ADA 


BD5005B . ADA 


BD5006B . ADA 

BD5006C . ADA 

BD5006D . ADA 

AD5007B . ADA 

AD5007C . ADA 

BD5007A. ADA 

AD50 1  IB . ADA 

AD50 1  IF . ADA 
AD50 1 1 J . ADA 
AD501 IN . ADA 
AD5  0 1 1R . ADA 

AD50 11C. ADA 
AD50 1  IQ . ADA 
AD501 IK . ADA 
AD501 10 . ADA 
AD50 1  IS . ADA 

AD501 ID . ADA 
AD501 1H. ADA 
AD50 1 1L . ADA 
AD501 IP . ADA 
AD501 IT. ADA 

AD50 1 2B . ADA 
AD50 1 2  F . ADA 
AD50 1 2 J . ADA 
AD5012N. ADA 
AD5012R. ADA 

AD50 1 2C . ADA 
AD50 1 2G . ADA 
AD5012K . ADA 
AD50 1 20 . ADA 
AD50 12S . ADA 

AD5  0 1  2D . ADA 
AD5012H. ADA 
AD5  0 1 2  L . ADA 
AD5012P. ADA 
AD5012T. ADA 

AD50 13B . ADA 
AD50 13F . ADA 
AD5013J. ADA 
AD5013N.ADA 

A  D  5  0 1 3  R . ADA 

AD50 1 3C . ADA 
AD5013G  ADA 
AD5013K. ADA 
AD50130 . ADA 
AD50 1 3S . ADA 

AD5013D. ADA 
AD5013H. ADA 
AD5013L. ADA 
AD5013P  ADA 
AD5013T. ADA 

AD5014B. ADA 
AD50 14F . ADA 
AD5014J . ADA 
AD5014N. ADA 
AD5014R. ADA 

AD5014C . ADA 
AD5014G. ADA 
AD5014K. ADA 
AD50140 . ADA 
AD5014S . ADA 

AD50 14D . ADA 
AD5014H. ADA 
AD5014L. ADA 
AD5014P . ADA 
AD5014T . ADA 

AD5022A . ADA 

AD5032A . ADA 

AD5042A . ADA 

BD5101B . ADA 

Address  Cl ause  Sample  Tests 
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N 
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--  BD5001A 

—  Check  that  the  express::  :  r.  an  address  clause  must  have 


--  the  type  SYSTEM  ADDRESS 

Check  illegal  address  i 


an  object 


uly  8  7 


-  *  Date  :  2 

-  -  Version:  1.2 

--  Author-  Capt  Dan  Joyce 


with  system: 
procedure  BD5. 


1  A 


subtype  bad_address_type  : 
bad_address:  bad_address 

bad_address2  positive 

bad_address3  integer  :r 

bad_address4  natural  :r 

bad  addressb  •  float  :  =  C 


■  teger ; 
>e  •  =  0 


o  b  j  e  c  1 1  :  integer; 

for  objecti  use  at  bad_address  1  ; 

--  Error  Address  must  be 
I  type  SYSTEM. ADDRESS 


objects  :  integer; 

for  object 2  use  at  bad_ad d r ess 2 ; 

--  Error-  Address  must  be 
--  cf  type  SYSTEM. ADDRESS 


o  b  j  e  c  1 3  :  integer; 

for  objects  use  at  bad_address3 ; 

--  Error.  Address  must  be 
--  of  type  SYSTEM. ADDRESS 


ob J  ect4  :  integer; 

for  obJect4  use  at  bad_address4 ; 

--  Error.  Address  must  be 
--  of  type  SYSTEM. ADDRESS 


ob j  ect5  :  integer; 

for  object5  use  at  bad_addr es s 5 ; 

--  Error.  Address  must  be 
--  of  type  SYSTEM. ADDRESS 

beg  1  n 
null; 

end  BD5001A; 
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--  AP50I1A 

--  Check  whether  an  address  clause  can  be  given  for  an  object 
--  declared  in  a  declarative  part. 

This  checks  for  enumeration  type  variables  declared  m  the 
declarative  parts  of  subprograms,  blocks,  and  package 
bodies 


--  Date:  24  July  87 

--  Version-  1.4 
--  Author-  Capt  Dan  Joyce 


with  SYSTEM: 

with  ADDRESS_PACKAQE ;  use  ADDRESS_PACKAGE ; 
with  REPORT:  use  REPORT; 
procedure  AD5011A  Is 

begin 


TEST ( ' AD50 1 1 A  ",  'Check  whether  an  address  clause  can  be  given 
'for  enumeration  type  variables  declared  in  the  '  & 
'declarative  parts  of  subprograms,  blocks  and  package  ' 
'bodies.  ' ) ; 

BLOCK  1  :  declare 

--  This  tests  the  declarative  part  of  subprograms 
procedure  prod  is 

type  enum_type  is  (red,  blue,  green)  ; 

enum_obJl:  enum_type ; 

for  enum_objl  use  at  obj ect_address  1  ; 
begin  --  prod 
nul  1  ; 

end  p  r  o  c  1  ; 

begin  --  BL0CK1 
null; 

end  BLOCK  1  ; 


BL0CK2 :  declare 

--  This  tests  the  declarative  part  of  blocks 
type  enum_type  is  (red,  blue,  green) ; 

enum_obJ 1 :  enum_type; 

for  enum  obj 1  use  at  object  address2; 


BL0CK2 


begin 
nui  1  ; 
end  BL0CK2 ; 


BL0CK3 :  declare 

--  This  tests  the  declarative  part  of  package  bodies 
package  PKG  is 
end  PKG; 

package  body  PKG  is 

type  enum_type  is  (red,  blue,  green)  ; 

enum_obJ 1 :  enum_type ; 

for  enum_obJ 1  use  at  ob j ect_address3 ; 
end  PKG; 

begin  --  BL0CK3 
null  ; 

end  BL0CK3 ; 

RESULT ; 
end  AD5  0 1 1  A ; 


Interrupts  Sample  Tests 


--  BD5102A 

--  Check  that  an  address  clause  cannot  be  specified  for 
--  an  entry  family. 

- -  Date :  8  Sep  87 

--  Version:  1.2 

--  Author:  Capt  Dan  Joyce 


with  system; 

with  ADDRESS_PACKAGE ;  use  ADDRESS_PACKAGE ; 
package  BD5102A  is 

type  i n terr up t_ 1  eve  1  is  range  0  .  .  2; 

task  taskl  is 

entry  f ami ly_entry 1  ( i n terrup t_ 1 e ve 1 )  ; 

for  f ami  1 y _entry 1  use  at  entry_address5 ; 

--  Illegal.  Can't  give 

--  address  clause 
- -  f ami  1 y  entry 

end  task  1  ; 
end  BD5 102A ; 


US  -A189  554  V At  I DATING  AND  EVALUATING  ADA'S  (TRADE  NARK)  J? 

REPRESENTATION  CLAUSES  AND  I  <U>  AIR  FORCE  INST  OF 
TECH  URIGHT-PATTERSON  AFB  OH  SCHOOL  OF  ENG I 
UNCLASSIFIED  D  0  JOVCE  DEC  87  AF IT/GCS/NA/87D-2  F/G  12/5  NL 
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package  body  BD5102A  is 

task  body  taskl  is 
begin 
loop 
select 

accept  f ami ly_entry 1 ( 0) 
or 

accept  f ami ly_entry 1 ( 1 ) 
or 

accept  f ami ly_en try  1 ( 2) 
end  select; 
end  loop; 
end  task  1 ; 
end  BD5102A; 
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A51 1  1A 

Check  that  if  an  implementation  supports  address  clauses 
for  entries,  such  a  clause  can  be  given  for  an  entry  of  a 
task  type  as  well  as  for  an  entry  of  a  single  task. 


Date  : 
Vers i on : 
Author : 


9  Sep  87 
1 . 5 

Capt  Dan  Joyce 


with  system; 

with  ADDRESS_PACKAGE ;  use  ADDRESS_PACKAGE ; 
package  AD5111A_PKG  is 

task  type  task_typel  is 
entry  entry  1 ; 

for  entryl  use  at  entry_address5 ; 
end  task_type 1 ; 

--  Legal.  Should  be  accepted 
--  if  implementation  supports 
--  entry  addresses. 

task_objectl  :  task_typel; 

task  task2  is 
entry  entry2; 

for  entry2  use  at  entry_address6 ; 
end  task2; 

--  Legal.  Should  be  accepted 
--  if  implementation  supports 
--  entry  addresses. 

end  AD5 111 A_PKG ; 


mmm 


package  body  AD5111A_PKG  is 
task  body  task_typel  is 
begin 

accept  entry  1 ; 
end  task_typel; 

task  body  task2  is 
begin 

accept  entry2; 
end  task2; 
end  AD5 111 A_PKG ; 

with  AD5 1 1 1 A_PKG;  use  AD5111A_PKG; 
with  REPORT;  use  REPORT; 
procedure  AD5111A  is 

begin 

--  The  next  two  task  calls  allow  the  tasks  to  terminate 
--  and  therefore  the  main  task  AD5111A  can  terminate 

task2 . entry 2 ; 
task_objectl . entry  1  ; 

TEST ( * AD5 1 1 1 A  ‘Check  that  an  address  clause  can  be  given  ‘ & 
‘entries  for  a  task  type  as  well  as  a  single  task  ‘); 
RESULT; 
end  AD5111A; 


Appendix  C:  Performance  Evaluation  Test  Software 

I  used  the  following  PIWG  programs  to  support  the 
benchmarks  developed  for  Chapter  13  features:  A000001, 
containing  the  package  DURATION_IO  for  reporting  timing 
results:  A000012.  containing  the  CPU_TIME_CLOCK  for  DEC  VAX 
computers:  A000021  and  A000022,  containing  the  specification 
and  body  of  the  REMOTE_GLOBAL  optimization  control  package.  I 
also  modified  the  PIWG  package  A000050  and  the  procedures 
A000052 ,  A000053 ,  A000054 ,  and  A000055  to  return  CPU  times  from 
in  the  format  I  needed  in  this  benchmark.  The  source  for  this 
package  and  these  modified  procedures  is  included  in  this 
appendix . 

The  machine  readable  code  for  these  modules  is  currently 
available  on  the  SIMTEL20 . ARPA  Ada  Software  repository,  in  the 
directory  PD : < PI WG . ADA) . 

The  performance  evaluation  tests  for  the  prototype  feature 
(enumeration  representation  clauses)  and  a  sample  of  the  tests 
for  interrupt  response  time  is  given  below.  The  machine 
readable  form  of  these  tests  is  available  from  the  Air  Force 
Institute  of  Technology,  Department  of  Mathematics  and  Computer 
Science  (ENC),  WPAFB  OH  45433. 

AI3  3  3C  Source  Code 

This  benchmark  was  designed  as  a  prototype  to  learn  more 
about  benchmarking  Chapter  13  features.  As  a  test  for  the 
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efficiency  of  a  compiler’s  implementation  of  enumeration 
representation  clauses  it  is  not  complete  because  it  tests  only 
the  successor  (’SUCC)  attribute.  A  complete  benchmark  would 
have  to  include  tests  for  a  wide  range  of  enumeration  objects 
with  all  of  the  enumeration  type  attributes  and  operations. 
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Test  Name:  A13_3_3C 
Author:  Capt  Dan  Joyce 

Date :  8  Jun  1987 

Test  Description:  This  test  is  designed  to  determine  the 
processing  overhead  associated  with  enumeration  types 
whose  representations  have  been  modified  with  an 
enumeration  representation  clause  from  Chapter  13 


with  A000050;  use  A000050; 

with  REMOTE  GLOBAL  :  use  REMOTE  GLOBAL 


--control  optimization 


procedure  A13_3_3C  is  --  main  procedure  to  execute 

type  enum^type  is  (aOO , aO 1 , a02 , a03 , a04 , a05 , a06 , a07 , a08 , a09 , 
alO.all,al2,al3,al4,al5,al6,al7,al8,al0, 
a20 , a 2  1  ,a22 ,a23 ,a24 ,a25 ,a26 , a27 , a28  ,  a29  , 
a30 , a3 1  , a32 , a33 , a34 , a35 ,a36 , a37 ,a38 ,a39  , 
a40 , a4 1 . a42 , a43 , a44 , a45 , a46 , a47 , a4B , a49 , 
a50 ,a51 , a52 , a53 , a54 , a55 , a56 , a57 , a58 , a59  , 
a60 , a 6 1 ,a62 , a63 , a64 , a65 , a66 ,a67 ,a66 ,a69 , 
a70 . a7 1 , a72 . a73 , a74 , a75 , a76 , a77 , a78 . a79 , 
a80 , a8 1 , a8  2  ,  a83 , a84 ,a85 ,a86 ,a87 , a88 ,a89 , 
a90 , a 9 1 ,a92,a93,a94,a95, a96 , a©7 , a 98 , a99 , 
alOO)  ; 


type  enum  type2  is  ( aOO , aO 1 , a02 , a03 , a04 , a05 , a06 , a07 , a08 , a09 , 
alO.all.an.alS.aM.alS.aie.an.alB.aig, 
a20,a21,a22,a23,a24,a25,a26,a27,a28,a29, 
a30  ,  a 3 1  ,a32 , a33 , a3  4 ,a35,a36,a37,a38,a39, 
a40,a41,a42,a43,a44,a45,a46,a47,a48,a49, 
a50.a51,a52,a53,a54,a55,a56,a57,a58,a59, 
a 6 0 , a 6  1  , a 6  2 , a63 , a 6  4 , a 6 5 , a66 ,a67 , a 6 8  ,  a 6 9  , 
a70 , a7 1 ,a72 ,a73 ,a74 , a75 , a76 , a77 , a78 , a79 . 
a80 ,a81 , a82 , a83 ,a84 , a85 ,a86 , a87 , a88 , a89 , 
a90,a91,a92,a93,a94,a95,a96,a97,a98,a99, 
alOO) ; 

for  enum_type2  use  (0,10,20,30,40,50,60,70,80,90, 

~  100 . 1  10 , 120 , 130 , 140 , 150 , 160 , 170 , 180 , 190 , 
200,210,220,230,240.250,260,270,280,290, 
300,310,320,330,340,350,360,370,380,390 , 
400,410,420,430,440,450,460,470,480,490, 
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500,510,520,530.540,550,560,570,580,590. 
600.610,620,630,640.650,660,670,680,690 . 
700,710,720,730,740,750,760,770,780,790 , 
800,810,820,830,840,850,860,870,880,890 , 
900 ,910,920,930,940 , 950 , 960,970 , 980 , 990 , 
1000) ; 


enum_obJect 
enura_ob J  ect2 


enum_type  :=  aOO; 
enum_type2  :=  aOO  ; 


begin 

AOO 0052 A ; 


--  Control  loop 


forJ  in  1  10  loop 

GLOBAL  : =  0  ; 

enum_obJect  :=  enum_type ’ f irst ; 
for  I  NS  I DE_LOOP  in  1  .  .  100  loop 

GLOBAL  :=  GLOBAL  ♦  A_0NE  ;  --  typical  control  loop  is 
REMOTE  ;  --  these  two  statements 

enum_object  :=  enum_type ’ succ (enum_obJ ect ) ; 
end  loop  ; 
end  loop  ; 


A000053A ; 
A000054 A ; 


—  Test  loop 


f or  J  in  1  10  loop 

GLOBAL  : =  0  ; 

enum_object2  :=  enum_type2 ’ f i rs t ; 
for  INSIDE_LOOP  in  1~ . .  100  loop 

GLOBAL  :=  GLOBAL  ♦  A_ONE ; 

REMOTE  ; 

enum_object2  :=  enum_type2 ’ succ (enum_ob j ect2)  ; 
end  loop  ; 
end  loop  ; 


a000055A ; 
end  A 1 3_3_3C ; 


A000050  Source  Code 
--  A000050 

--  This  is  a  package  that  contains  modified  versions  of  A000051 
--  thru  A000054 .  These  procedures  save  the  wall  and  c.u  time 
--  in  variables  in  the  A000050  package  rather  than  writing  them 
--  to  a  file  each  time  a  measurement  is  taken.  I  am  concerned 
--  that  the  overhead  for  the  1/0  is  distorting  the  timing 
--  measurements .  Therefore,  the  data  will  be  written  at  the 
--  end,  after  all  measurements  have  been  taken 


--  USAGE  :  A000052 A  (1) 

control  procedure 
A000053A  (2) 

A000054A  (3) 

teat  procedure 
A000055A  (4) 

--  RESULT  : 

(  (4)  -  (3)  )  -  (  (2)  -  (1)  )  la  the  meaaurement 

The  aecond  expression  takes  out  the  time  to  make  the 
measurement.  As  a  check,  (3)  -  (2)  should  be  close  to 
(2)  -  (1) 

with  CPU_TIME_CLOCK  ;  --  various  choices  on  tape 

with  CALENDAR  ;  --  used  for  WALL  clock  times 
with  TEXT_IO  ;  --  for  printing  times 

with  DURATION_IO  ;  --  for  printing  times 


package  A000050  is 
CPU_SECONDS_START_CONTROL 
CPU_ SECONDS _STOP_CONTROL 
CPU_SECONDS_START_TEST 
CPU_SECONDS_STOP_TEST 
CPU_SECONDS_DIFF_CONTROL 
CPU_SECONDS_DI FF_TEST 
CPU  SECONDS  DIFF 


DURATION 

DURATION 

DURATION 

DURATION 

DURATION 

DURATION 

DURATION 


WALL_SECONDS_START_CONTROL 
WALL_SECONDS_STOP_ CONTROL 
WALL_SECONDS_START_TEST 
WALL_SECONDS_STOP_TEST 
WALL_SECONDS_DI FF_CONTROL 
WALL_SECONDS_DIFF_TEST 
WALL  SECONDS  DIFF 


DURATION 

DURATION 

DURATION 

DURATION 

DURATION 

DURATION 

DURATION 


procedure  A000052A 
procedure  A000053A 
procedure  A000054A 
procedure  A000055A 
end  A000050 ; 


package  body  A000050  is 
procedure  A000052A  is 


begin 

CPU_SECONDS  START_ CONTROL  :=  CPU_TIME_CLOCK ; 
WALL_ SECONDS _START_CONTROL  := 

CALENDAR . SEC0n5s (CALENDAR . CLOCK)  ; 
end  A000052A; 


procedure  A000053A  is 


beg  i  n 

CPU_SECONDS_JTOP_CONTROL  :  =  CPU_TI ME_CLOCK ; 
WALL_ SECONDS _STOP_ CONTROL  : = 

CALENDAR. SECONDS ( CALENDAR . CLOCK ) ; 
end  A000053A; 

procedure  A000054A  is 


begin 

CPU_SECONDS_START_TEST  :=  CPU_TI ME_CLOCK ; 

WALL_ SECONDS _ ST ART_TEST  :=  CALENDAR . SECONDS (CALENDAR . CLOCK) 
end  A000054 A ; 

procedure  A000055A  is 

MY_F I LE  :TEXT_IO.FILE_TYPE; 
begin 

CPU_SECONDS_STOP_TEST  :=  CPU_TIME_CLOCK ; 

WALL_SECONDS_STOP_TEST  :=  CALENDAR . SECONDS (CALENDAR . CLOCK) ; 


CPU_SECONDS_DIFF_TEST  :=  CPU_SECONDS_STOP_TEST  - 

CPU_SECONDS_START  TEST; 

CPU_SECONDS_DI FF_CONTROL  :  =  CPU_SECONDS_STOP_CONTROL  - 

CPU  SECONDS_START_CONTROL ; 
CPU_SECONDS__DIFF  :  =  CPU.SECONDS  DIFF  TEST  - 

CPU_ SECONDS _D I FF_ CONTROL ; 

WALL_SECONDS_DI FF_TEST  :=  WALL_SECONDS_STOP_TEST  - 

WALL_SECONDS_START_TEST ; 

WALL_SECONDS_DIFF_CONTROL  :=  WALL_SECONDS_STOP_CONTROL  - 

WALL_SECONDS_START_CONTROL ; 
WALL_SECONDS_DIFF  :  =  WALL_SECONDS_DIFF_TEST  - 

WALL_SECONDS_DIFF_CONTROL ; 

TEXT_IO. CREATE (MY_FILE,  TEXT_IO . OUT_FILE ,  •AOOOOSOD’); 

TEXT_IO . NEWLINE (MY_FILE) ; 

TEXT_IO . PUT (MY_FILE ,  *  CPU  SECONDS  DIFF  CONTROL:  *); 
DURATION_IO . PUT (MY_FILE , CPU  SECONDS  DIFF_CONTROL) ; 

TEXT_ 10 . NEW_LINE (MY_FILE , 1) ; 

TEXT_IO . PUt7mY_FILE ,  *  CPU  SECONDS  DIFF  TEST:  "); 

DURATION_IO . PUT (MY_FILE , CPU  SECONDS  DIFF  TEST); 

TEXT_IO . NEW_LINE (MY_FILE , 1) ; 

TEXT_IO . PUT7mY_FILE ,  *  CPU  SECONDS  DIFFERENCE:  '); 

DURAT ION_IO . PUT (MY_FILE , CPU_SECONDS_DIFF) ; 

TEXT_I0.NEW_LINE(MY_FILE,2)  ; 

TEXT_IO.PUtTmY_FILE,  -WALL  SECONDS  DIFF  CONTROL:  ’); 
DURATION  10. PUT(MY_FILE, WALL  SECONDS  DIFF  CONTROL); 

TEXT  10. NEW  LINE (MY_FILE , I) ; 


TEXT_IO . PUT (MY_FILE ,  'WALL  SECONDS  DIFF  TEST: 
DURATION  10 . PUT (MY  FILE , WALL, SECONDS.D IFF  TEST); 
TEXT_IO. NEW, LINE (MY, FILE ,  1 )  ; 

TEXT_IO . PUT (MY_FILE ,  ‘WALL  SECONDS  DIFFERENCE: 
DURATION, 10 . PUT (MY_FILE , WALL  SECONDS  DIFF); 
TEXT_IO. CLOSE (MY  FILE); 
end  A000055A ; 
end  A000050; 


‘)  ; 

■)  ; 


Sample  Benchmark  for  Interrupt  Delay  Time 


--  INT_TEST4 

This  Is  a  benchmark  that  will  measure  the  Interrupt  delay 
time  associated  with  a  task  as  an  interrupt  handler. 

Task  I NT_HANDLE_2_T0_ 1 4  has  an  entry  tied  to  Interrupt  3 
with  an  address  clause.  The  accept  block  of  this  task 
should  be  entered  whenever  interrupt  3  is  raised. 

This  benchmark  will  raise  MIL-STD- 1750A  interrupt  3 
(a  floating  point  overflow)  by  causing  a  floating  point 
overflow  in  the  main  procedure . 

This  benchmark  calls  RESET_INT_VECT0RS_7_AND_9  and 
--  GET_ALL_TIMES  in  package  TIME_PACKAGE_ 1750 A  to  set  up  and 
retrieve  precise  CPU  time  measurements  that  are  not 
available  with  package  CALENDAR. 

This  benchmark  has  1  TASK  with  10  entries,  each  tied  to 
a  1750a  interrupt. 

Author:  Capt  Dan  Joyce 

--  Date:  27  Sept  87  1325 
Version :  2.4 


package  GLOBAL, I NTERRUPT_MAKER4  is 
function  FL0AT_RETURN  return  float; 
end  GLOBAL. I NTERRUPT.MAKER4 ; 

with  TIME .PACKAGE, 1 750 A ;  use  TI ME .PACKAGE, 1 750 A ; 
with  GLOBAL, I NTERRUPT.MAKER4 ; 
with  TEXT.IO;  use  TEXT.I0; 
procedure  INT.TEST4  is 

package  time, 1750a_io  is  new  FL0AT.I0 ( time, 1750a) ; 
use  time ,1750 a, io; 

float.object  :  FLOAT  :=  0.500000  »  2.0  * »  127; 

max.values  :  constant  integer  :  =  100; 

type  TIME.ARRAY.TYPE  is  array  ( 1 .. max.values )  of  TIME.1750A; 


Variables  for  statistical  calculations 
The  address  clause  is  used  so  those  memory 


--  locations  may  be  examined  on  the  1750A  to 
--  verify  the  accuracy  of  the  values  reported 


mean  :  TIME_1750A  :=  0.0; 
for  mean  use  at  16*6000*; 

variance  :  TIME_1750A  :=  0.0: 
for  variance  use  at  16*6004*; 

sum_del_tim  :  TIME_1750A  :=  0.0; 
for  sum_del_tim  use  at  16*6010*; 

sum_del_tim2  :  TIME_1750A  :=  0.0; 
for  sum_del_tim2  use  at  16*6014*; 


--  Time  collection  Variables 

bef ore_interrupt  :  TIME_ARRAY_TYPE  :=  (others  =>  0.0) 

af ter_interrupt  :  TIME_ARRAY_TYPE  :=  (others  =>  0.0) 

clock_bias_start  :  TIME_ARRAY_TYPE  :=  (others  =>  0.0) 

clock_bias_stop  :  TIME_ARRAY_TYPE  :=  (others  =>  0.0) 

int_delay  :  T I ME_ ARRAY_T YPE  :=  (others  =>  0.0) 

for  int_delay  use  at  16*7000*; 

start_benchmark  :  TIME_1750A  :=  0.0; 

for  start_benchmark  use  at  16*6020*; 

stopbenchmark  :  TIME_1750A  :=  0.0; 

for  stop_benchmark  use  at  16*6024*; 

main_timera_return  :  TIME_1750A  :=  0.0; 

main_dummyb_return  :  TIME_1750A  :=  0.0; 

task_timera_return  :  TIME_1750A  :=  0.0; 

pragma  SHARED ( task_timera_return) ; 
task_dummya_return  :  TIME_1750A  :=  0.0; 
pragma  SHARED ( task_dummya_re turn ) ; 
task_dummyb_return  :  TIME_1750A  :=  0.0; 
pragma  SHARED ( task_dummyb_return) ; 


--  Interrupt  Handling  Task  Specifications 

task  INT_HANDLE_2_T0_ 1 4  is 
pragma  PRIORITy73)~ 
entry  interrupt_2; 
for  interrupt_2  use  at  2; 
entry  interrupt_3; 
for  interrupt_3  use  at  3; 


entry  interrupt_4; 
for  interrupt_4  use  at  4; 
entry  interrupt_6; 
for  interrupt_6  use  at  6; 
entry  interrupt_8; 
for  interrupt_8  use  at  8; 
entry  interrupt_ 10 ; 
for  interrupt_10  use  at  10 
entry  interrupt_ 1 1 ; 
for  interrupt_ll  use  at  11 
entry  interrupt_12 ; 
for  interrupt_12  use  at  12 
entry  interrupt_ 13 ; 
for  interrupt_13  use  at  13 
entry  interrupt_14 ; 
for  lnterrupt_14  use  at  14 
end  INT_HANDLE_2_T0_ 1 4 ; 


--  Interrupt  Handling  Task  Bodies 


--  This  is  the  task  that  will  handle  the  overflow 


task  body  INT_HANDLE_2_T0_ 14  is 
befin 
1  jop 

select 

accept  interrupt_2  do 

get_al l_times ( task_dummya_return , 
task_dummyb_return) ; 
put_line(*in  interrupt_2  accept'); 
end  interrupt_2; 
or 

accept  interrupt_3  do 


--  This  is  the  accept  that  handles  the  -- 
--  floating  point  overflow 


get_all_times(task_timera_return, 
task_dummyb_return) ; 

end  interrupt_3; 
or 

accept  interrupt_4  do 

get_all_time8( task_dummya_re turn , 
task_dummyb_return) ; 
put_line(’in  interrupt_4  accept*); 

end  interrupt_4; 
or 

accept  interrupt_6  do 

get_al l_times ( task_dummya_return , 
task_dummyb_return) ; 


put_line('in  interrupt_6  accept'); 
end  interrupt_6; 
or 

accept  interrupt_8  do 

get_all_times( task_dummya_return , 
task_dummyb_return)  ; 
put_line('in  interrupt_8  accept'); 
end  lnterrupt_8; 
or 

accept  interrupt_10  do 

get_all_tlmea( task_dummya_return , 
task_dummyb_return) ; 
put_line('in  interrupt_10  accept'); 
end  i nterrupt_ 1 0 ; 
or 

accept  interrupt_ll  do 

get_all_times( t as k _ dummy a_re turn , 
task_dummyb_return) ; 
put_line('in  interrupt, 1 1  accept'); 
end  lnterrupt_ 1 1 ; 
or 

accept  interrupt_12  do 

get_all_times ( t ask_ dummy a_re turn , 
task_dummyb_return) ; 
put_line('in  interrupt_12  accept' ) ; 
end  1 nterrupt, 1 2 ; 
or 

accept  interrupt_13  do 

get_all_times ( t ask _dummya_re turn , 
task_dummyb_return) ; 
put_line('in  interrupt_13  accept’); 
end  interrupt, 13 ; 
or 

accept  interrupt_14  do 

get_all_times( task_dummya_return , 
task_dummyb_return) ; 
put_line('in  lnterrupt_14  accept'); 
end  1 nterrupt, 1 4 ; 
end  select; 
end  loop; 

end  I NT_HANDLE_2_T0_ 1 4 ; 


--  This  procedure  calculates  the  mean  and  variance 
--  for  the  interrupt  delay  time 

procedure  STATI STICS_AND_RESULTS  is 

elapsed_bench_time  :  time_1750a  :=  0.0; 
n  :time_1750a:=0.0; 


sum  del  tim2 


0.0; 


for  i  In  1  max_values  loop 


--  The  bias  of  the  GET_ALL_TIMES  oall  is 
--  added  back  in 


int_delay(i)  :=  af ter_ i nterrupt ( i )  - 

(bef ore_interrupt ( i )  +  elock_bias_stop T i )  - 

olook_bias_start ( i )  ); 
sum_del_tim  :=  sum_del_tim  +  int_delay ( i ) ; 
sum_del_tim2  :=  sum_del_tim2  + 

( i nt_de 1  ay  (  i )  *  i nt_de 1  ay ( i ) )  ; 

end  loop; 


n  :=  time_ 1750a (max_values ) ; 
mean  :=  sum_del_tim  /  n; 

variance  :=  (sum_del_tim2  -  (n*mean«mean) )  /  (  n  -  1.0  ); 

new_ line; 

put ( ‘ start  : ' ) ; 

put (start_benchraark)  ; 

put ( '  stop  :  '  )  ; 

put (stop_benchmark)  ; 

put ( '  elapsed  time  :  '); 

elapsed_bench_ time  :=  stop_benchmark  -  star t_benchmark ; 
put lelapsed_bench_time)  ; 

new_ line; 
put ( '  n  =  ' )  ; 

put (n1  ; 

put ( '  mean  =  * )  ; 

put ( mean ) ; 
put ( '  var  =  '  )  ; 
put ( variance )  ; 
new_ line; 

end  STATISTICS_AND_RESULTS ; 

begin  --  INT_TEST4 

RESET_ I NT_ VECTORS _7_AND_ 9 ; 

GET_ALL_TIMES ( s tart_benchmark , 

main_dummyb_return) ; 

for  i  in  1  max_values  loop 


--  The  first  2  clock  calls  are  used  to  factor  out 
--  the  time  a  GET  ALL  TIMES  call  will  take 
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GET_ALL_TIMES (clock_bias_start(i)  , 
main_dummyb_return)  ; 

GET_ALL_TIMES (clock_bias_stop(i) , 
main_dummyb_return) ; 

GET_ALL_TIMES (before_interrupt(i)  , 
main_dumrayb_return)  ; 
float_object  := 

f loat_ob j  ect  +  GLOBAL_ I NTERRUPT_MAKER4 . FLO AT_ RETURN ; 

--  This  will  cause  an  overflow 
af ter_interrupt ( i )  :=  task_t imera_re turn ; 


GET_ALL_TI MES ( s  top_benchmark , 

main_dummyb_return) ; 


abort  I NT, HANDLE, 2 _ TO _ 1 4 ; 
ST AT  I  ST I CS_ AND, RESULTS ; 

end  I NT  TEST4 ; 


package  body  GLOBAL, INTERRUPT_MAKER4  is 
function  FLOAT_RETURN  return  float  is 
begin 

return  0.50000  *  2.0  #*  127; 
end  FLOAT_RETURN ; 
end  GLOBAL  INTERRUPT  MAKER4 ; 


This  appendix  contains  the  results  of  the  validation  tests 


that  were  run  on  the  three 

compiler  either  passes  the 

ruled  inapplicable  because 

feature  in  the  manner  it  is 

Enumeration  Representation 

compilers  in  this  thesis.  A 

test,  fails  the  test,  or  a  te 

the  compiler  does  not  support 

tested,  indicated  by  N/A. 

Clauses 

Test 

Compiler  A 

BD3001A 

Passed 

BD3002A 

Passed 

BD3004A 

Passed 

BD3012A 

Passed 

Address 

Clauses  and  Interrupts 

Test 

Compiler  A 

Compiler  B 

Compiler  C 

BD5001A 

Passed 

Passed 

Passed 

BD5002A 

Passed 

Passed 

Passed 

BD5002B 

N/A 

N/A 

N/A 

BD5002C 

N/A 

N/A 

N/A 

BD5002D 

N/A 

N/A 

N/A 

BD5002E 

N/A 

N/A 

N/A 

AD5003A 

Passed 

Passed 

Passed 

AD5003B 

Passed 

Passed 

Passed 

AD5003C 

Passed 

Passed 

Passed 

AD5003D 

Passed 

Passed 

Passed 

AD5003E 

Passed 

Passed 

Passed 

BD5004A 

Passed 

Passed 

Passed 

BD5004B 

Passed 

Passed 

Passed 

BD5004C 

Passed 

Passed 

Passed 

BD5005A 

Passed 

Passed 

Passed 

BD5005B 

Passed 

Passed 

Passed 

99 


♦ 

Test 

Compiler  A 

Compiler  B 

■  -W  *-▼  —  W  -  W  "  W-TIT'TW ■»*  W"1 

Compiler  C 

v*V 

r 

BD5006A 

Passed 

Passed 

Passed 

V. 

BD5006B 

Passed 

Passed 

Passed 

BD5006C 

Passed 

Passed 

Passed 

BD5006D 

Passed 

Passed 

Passed 

BD5006E 

Passed 

Passed 

Passed 

.  > 

AD5007A 

N/A 

N/A 

N/A 

.*;*» 

•j!|r 

AD5007B 

N/A 

N/A 

N/A 

AD5007C 

N/A 

N/A 

N/A 

& 

BD5007A 

N/A 

N/A 

N/A 

*V« 

l 

BD5008A 

Passed 

Passed 

Passed 

i 

AD50  1  1 A 

Passed 

Passed 

Passed 

AD501  IB 

Passed 

Passed 

Passed 

$ 

3£S 

AD501  1C 

Passed 

Passed 

Passed 

AD501  ID 

Passed 

Passed 

Passed 

n 

AD501  IE 

Passed 

Passed 

Passed 

AD501  IF 

Passed 

Passed 

Passed 

AD 50  1  1G 

Passed 

Passed 

Passed 

5^ 

AD 50  1  1H 

Passed 

Passed 

Passed 

ssg 

AD501  1 1 

Passed 

Passed 

Passed 

AD501  1 J 

Passed 

Passed 

Passed 

ta 

n.r 

AD501  IK 

N/A 

N/A 

N/A 

§A 

AD501  1L 

N/A 

N/A 

N/A 

M 

AD501 1M 

N/A 

N/A 

N/A 

AD501 IN 

N/A 

N/A 

N/A 

v  M 

-j 

AD501  10 

N/A 

N/A 

N/A 

AD  50  1  l"1 

N/A 

N/A 

N/A 

•t*s 

4*5 

4*5 

•ns 

AD501 IQ 

N/A 

N/A 

N/A 

AD5012A 

Passed 

Passed 

Passed 

a 

AD5012B 

Passed 

Passed 

Passed 

M 

ijS 

AD5012C 

Passed 

Passed 

Passed 

AD5012D 

Passed 

Passed 

Passed 

& 

AD5012E 

Passed 

Passed 

Passed 

W 

'*.*!< 

AD5012F 

Passed 

Passed 

Passed 

TT 

AD5012Q 

Passed 

Passed 

Passed 

AD5012H 

Passed 

Passed 

Passed 

AD5012I 

Passed 

Passed 

Passed 

AD5012J 

Passed 

Passed 

Passed 

$ 

AD5012K 

N/A 

N/A 

N/A 

AD5012L 

N/A 

N/A 

N/A 

AD5012M 

N/A 

N/A 

N/A 

1 

$ 

100 

Test 


Compiler  A 


Compiler  B 


Compiler  C 


AD5012N 

N/A 

N/A 

N/A 

AD50120 

N/A 

N/A 

N/A 

• 

AD5012P 

N/A 

N/A 

N/A 

AD5012Q 

N/A 

N/A 

N/A 

AD5013A 

Passed 

Passed 

Passed 

AD5013B 

Passed 

Passed 

Passed 

AD5013C 

Passed 

Passed 

Passed 

AD5013D 

Passed 

Passed 

Passed 

AD5013E 

Passed 

Passed 

Passed 

AD5013F 

Passed 

Passed 

Passed 

AD50130 

Passed 

Passed 

Passed 

AD5013H 

Passed 

Passed 

Passed 

AD5013I 

Passed 

Passed 

Passed 

AD5013J 

Passed 

Passed 

Passed 

AD5013K 

N/A 

N/A 

N/A 

AD5013L 

N/A 

N/A 

N/A 

AD5013M 

N/A 

N/A 

N/A 

AD5013N 

N/A 

N/A 

N/A 

AD50130 

N/A 

N/A 

N/A 

AD5013P 

N/A 

N/A 

N/A 

ADS013Q 

N/A 

N/A 

N/A 

AD5013R 

N/A 

N/A 

N/A 

AD5013S 

N/A 

N/A 

N/A 

AD 50  1 4 A 

Passed 

Passed 

Passed 

AD5014B 

Passed 

Passed 

Passed 

AD5014C 

Passed 

Passed 

Passed 

AD5014D 

Passed 

Passed 

Passed 

AD5014E 

Passed 

Passed 

Passed 

AD5014F 

Passed 

Passed 

Passed 

AD5014Q 

Passed 

Passed 

Passed 

AD5014H 

Passed 

Passed 

Passed 

AD5014I 

Passed 

Passed 

Passed 

AD5014J 

Passed 

Passed 

Passed 

AD5014K 

N/A 

N/A 

N/A 

AD5014L 

N/A 

N/A 

N/A 

AD5014M 

N/A 

N/A 

N/A 

AD5014N 

N/A 

N/A 

N/A 

AD50140 

N/A 

N/A 

N/A 

AD5014P 

N/A 

N/A 

N/A 

AD5014Q 

N/A 

N/A 

N/A 

AD5014R 

N/A 

N/A 

N/A 

AD5014S 

N/A 

N/A 

N/A 
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Test 

Compiler  A 

Compiler  B 

Compiler  C 

AD5021A 

N/A 

N/A 

N/A 

AD5022A 

N/A 

N/A 

N/A 

AD5031A 

N/A 

N/A 

N/A 

AD5032A 

N/A 

N/A 

N/A 

AD5041A 

N/A 

N/A 

N/A 

AD5042A 

N/A 

N/A 

N/A 

BD5101A 

N/A 

Passed 

N/A 

BD5101B 

N/A 

Passed 

N/A 

BD5102A 

N/A 

FAILED5 

N/A 

BD5103A 

N/A 

Passed 

N/A 

BD5104A 

N/A 

Passed 

N/A 

AD5 1 1 1A 

N/A 

Passed 

N/A 

Totals 


Compiler  A 


Compiler  B 


Compiler  C 


Appendix  E:  Performance  Evaluation  Test  Results 
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Results  of  Prototype  Benchmark 

The  results  shown  below  are  the  differences  In  the  control 
and  test  loop  execution  times,  in  seconds,  of  the  A13_3_3C 
benchmark  ( tes t_l oop_t 1  me  -  control_loop_time)  ;  they  are 
presented  here  as  an  example  of  the  results  obtained  from  this 
benchmark.  The  numbers  in  square  brackets  index  the  trial 
number  of  the  first  result  in  that  row. 

Chapter  4  describes  how  the  test  version  of  the  benchmark 
could  be  faster  than  the  control  version,  generating  the 
negative  difference. 


i 

i 

r* 
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Compiler  A  Results 


-0 . 0300 

-0 .0100 

0.0200 

0 . 0700 

0 . 0400 

0 . 000  1 

0 . 0099 

0 . 0 

-0 . 0601 

-0.0100 

til] 

0.0100 

0 . 0200 

-0 . 0200 

0.0 

-0.0100 

0 . 0 

-0 . 000  1 

-0 . 0200 

0.0100 

0 . 0200 

[21  ] 

0 . 0200 

-0.0100 

0 . 0200 

0 .0100 

0 . 0990 

-0 . 4800 

-0 . 4600 

-0 . 4700 

-0 . 4401 

-0 . 4200 

[31  ] 

0.0100 

0 . 0 

-0 . 0300 

-0.0100 

0 . 0 

0 . 0200 

0 . 0001 

-0 . 0200 

0 .0199 

-0 . 0200 

[41  ] 

-0 . 0300 

0 . 0 

-0 . 0200 

0 . 0 

0 . 0990 

0 . 0 

0.0199 

0 . 0100 

0 . 0990 

0 . 0 

[51  ] 

-0 . 0099 

-0 . 0700 

-0.0100 

0 .0100 

0 . 0300 

-0 . 0400 

0 . 0200 

-0 . 0200 

0 . 0100 

-0.0100 

[61  ] 

0 . 0400 

0 . 0099 

0 . 0200 

0 . 0 

-0.0100 

-0 . 0200 

0 . 0200 

0 . 0 

-0.0100 

0 .0100 

[71  ] 

-0.0100 

0 . 0 

0 . 0100 

-0 . 0200 

0.0100 

Mean  = 

-0  . 

0264453 

Seconds , 

Standard  Deviation  = 


0.1186431  Seconds 
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end ix  F :  Detailed  Description  of  Time  Package  1750A 


I 

I 


Introduction 

This  appendix  describes  the  detailed  development  of  the 
TIME_PACKAGE_ 1 750A ,  which  contains  three  procedures  used  to 
return  the  current  elapsed  time  from  the  timer  registers 
available  on  the  MIL-STD- 1 750A  archi tecture .  This  appendix 
explains  how  each  of  these  procedures  was  designed,  followed  by 
the  assembly  language  and  Ada  source  code  for  these 
procedures.  Much  of  the  information  found  in  this  appendix  is 
extracted  from  MIL-STD- 1 750A  (DoD,1982)  --  the  reader  is 
directed  to  that  document  for  further  detail  on  interrupt 
handling  and  assembly  Instructions  for  the  MIL-STD- 1750A 
archi tecture . 

A  crucial  link  in  the  development  of  benchmarks  to 
measure  interrupt  response  time  was  the  development  of  a  method 
for  precise,  accurate  measurement  of  the  elapsed  CPU  time  for 
this  operation.  TIME_PACKAGE_ 1750A  consists  of  three 
functions:  (1)  an  assembly  language  routine  that  resets  and 

redefines  the  interrupt  service  routines  for  MIL-STD- 1750A 
interrupts,  (2)  an  assembly  routine  to  retrieve  the  current 
value  of  the  two  MIL-STD- 1750A  timer  registers  and  the  number 
of  interrupts  that  have  occurred,  and  (3)  an  Ada  package  that 
other  Ada  procedures  can  'with*  to  retrieve  CPU  times.  Each  of 
these  will  be  described  in  detail  below. 
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Background 

Among  its  general  purpose  registers,  the  MIL-STD- 1 750A  has 
two  16-bit  registers  known  as  Timer  A  and  Timer  B.  When  a 
MIL-STD- 1750A  processor  is  started  up,  or  reset,  both  Timer  A 
and  Timer  B  are  set  to  zero  and  are  incremented  every  10  and 
100  ml cr oseconds ,  respectively,  and  count  in  the  following 
sequence : 


000016,  0001  j  g . 7FFF16-  800016  . FFFF16-  000016' 

0001 16  •• 

Whenever  the  timers  increment  from  FFFF,.  to  0000,.,  they  each 

16  16 

generate  a  MIL-STD- 1750A  interrupt.  Timer  A  generates 
interrupt  7  and  Timer  b  generates  interrupt  9  (DoD,  1982:19). 
The  current  elapsed  time,  then,  may  be  calculated  using  the 
following  formulas: 

El  =  [  (I  «  65,536)  ♦  T  )  *  10  /  1000000.0  seconds 
a  a  a 

or  , 

El,  =  [  (I,  *  65,536)  ♦  Tv  ]  *  100  /1000000.0  seconds 
b  b  b 

where 

El^  =  Elapsed  time  (using  Timer  A) 

Elfc  =  Elapsed  time  (using  Timer  B) 

I  =  number  of  Timer  A  interrupts 

1^  =  number  of  Timer  B  interrupts 

T&  =  current  value  of  Timer  A  register 

T^  =  current  value  of  Timer  B  register 

Although  both  Timers  should  report  similar  results,  with  Timer 
A  having  more  precision,  both  timers  were  used  in 
T I ME_PACKAQE_ 1 750A  as  a  check  to  ensure  that  the  values  being 


returned  were  valid.  In  order  to  calculate  the  elapsed  time, 

T I ME_PACKAGE_ 1 750A  must  keep  track  of  the  number  of  times 
interrupts  7  and  9  have  occurred,  retrieve  the  values  of  the 
Timer  A  and  B  registers,  and  perform  the  conversion  shown 
above  . 

Interrupt  Counting 

In  order  to  count  the  number  of  interrupts  7  and  9  that 
occurred ,  I  had  to  modify  the  interrupt  linkage  pointers  for 
those  two  interrupts.  I  wrote  an  assembly  language  routine 
that  is  called  RESETIV,  which  resets  the  service  pointers  for 
those  interrupts. 

Whenever  an  interrupt  occurs,  the  current  state  of  the  CPU  is 
saved,  and  the  CPU  reads  a  series  of  three  16-bit  words 
starting  at  the  memory  location  indicated  by  the  value  in  the 
Service  Pointer.  The  first  two  words  are  loaded  into  the 
Interrupt  Mask  and  the  Status  Word,  respectively.  The  third 
word  contains  the  new  instruction  counter,  and  is  the  first 
instruction  of  the  interrupt  service  routine.  When  RESETIV  is 
called,  it  resets  the  service  pointer  for  interrupt  7  (or  9)  to 
another  three  words  of  memory,  the  third  being  the  address  of 
the  first  instruction  of  the  new  interrupt  7  (or  9)  service 
routine  declared  in  RESETIV.  All  this  routine  does  is  add  one 
to  memory  location  500  (or  501  for  Interrupt  9) .  These  memory 
locations  are  reserved  for  this  use  because  two  16  bit  integers 
are  declared  in  the  TIME_PACKAGE_ 1750A  and  assigned  this 


address  with  an  address  clause. 


RESETIV  is  linked  to  the  Ada  procedure 
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RESET_ I NT_VECTORS_7_AND_9  with  a  pragma  INTERFACE  statement. 
When  a  procedure  calls  RESET_ I NT_VECT0RS_7_AND_9  then  the 
service  pointers  are  reset  and  the  interrupt  service  routines 
defined  in  RESETIV  start  keeping  the  interrupt  count. 

The  RESETIV  source  code  is  given  below. 

RESETIV  Source  Code 


RESETIV 

Name:  Reset  Interrupt  Vectors 

Description:  This  assembly  language  routine  will  reset  the 

interrupt  vectors  for  MIL-STD- 1750A  interrupts  7  and  9, 
which  correspond  to  the  timer  A  and  timer  B  clocks 
resetting  to  0000  (from  FFFF) ,  or  "wrapping  around".  The 
Interrupt  service  routines  provided  in  this  program  will 
increment  a  counter  that  keeps  track  of  the  number  of 
interrupts.  By  returning  the  current  value  of  the  timers 
and  the  number  of  times  they  have  wrapped  around,  one  may 
determine  the  current  elapsed  time  without  calling  a 
predefined  [slower]  system  time  routine,  such  as  Ada’s 
( tm)  CALENDAR  package. 

Re  f  erences : 

MIL-STD- 1750A ,  (notice  1),  21  May  1982,  U.S. 

Printing  Office.  [Pages  19-21  explain  interrupt  pointers, 
service  routines,  etc.] 

Author:  Capt  Dan  Joyce  (with  much  help  from  lLt  Marc  Pitarys) 
Date :  6  Sep  87 

Version:  1.4 


;  R6 

EQU 

6 

R7 

EQU 

7 

R8 

EQU 

8 

R9 

EQU 

9 

RIO 

EQU 

10 

\  R 1  1 

EQU 

1 1 

.  R 1 2 

EQU 

12 

)  R 1 3 

EQU 

13 

j  R 1  4 

EQU 

14 

R 1 5 

EQU 

15 

JC 

7 .RESETIV 

;  BRANCH  TO  THE  PROGRAM  BEGIN 

ORG 

00500 

u  TICKNTA 

DATAT 

0000 

;TickntA  &  B  count  the  number  of  times 

J  TICKNTB 

DATAT 

0000 

;TlmerA  &  B  have  wrapped  around  (0000) 

}  IVEC7 

DATAT 

EVEN 

V7ISR 

[  IVEC9 

| 

DATAT 

EVEN 

V9ISR 

R  V7ISR 

DATAT 

0 

; New  Int  Mask:  MASK  ALL  INTERRUPTS 

w 

5 

DATAT 

0 

;New  Status  Word 

* 

> 

\ 

DATAT 

EVEN 

1 7 1  SR 

; New  Instruction  Counter 

j  V9ISR 

DATAT 

0 

; New  Int  Mask:  MASK  ALL  INTERRUPTS 

I 

DATAT 

0 

;New  Status  Word 

b 

DATAT 

EVEN 

1 9 1  SR 

;New  Instruction  Counter 

•  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — 

:  ;  INTERRUPT  HANDLER 

FOR  TIMER  A 

|  ; I QW  REST  100 

J  EVEN 

J  1 7 1  SR  TAH 

Stop  Timer  A 

*  TBH 

Stop  Timer  B 

\  I NCM  1,0500 

INCREMENT  THE  CLOCK  TICK  COUNT 

i  TAS 

Restart  Timer  A 

j  TBS 

Restart  Timer  B 

[  ENBL 

RE-ENABLE  INTERRUPTS 

l  LST I  0002E 

Reload  old  status 

; 

[2E  +  0]  ->  MK, 

C2E  ♦  1]  ->  SW, 

«• 

h 

[2E  +  2]  ->  IC  (RETURN) 

l 

f  ;  INTERRUPT  HANDLER 

FOR  TIMER  B 

£  EVEN 

J  1 9 1  SR  TAH 

Stop  Timer  A 

f  TBH 

Stop  Timer  B 

;  I NCM  1,0501 

INCREMENT  THE  CLOCK  TICK  COUNT 

|  TAS 

Restart  Timer  A 

J  TBS 

Restart  Timer  B 

Vi 

fc 

s 

% 

1 

L 
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ENBL 

RE-ENABLE  INTERRUPTS 

LST I 

i 

00032 

Reload  old  status  (see  above) 

* 

RESETIV  DSBL 

Disable  Interrupts 

PSHM 

R0  ,  R 1 

Save  RO  and  R1 

SR 

R0  ,  RO 

Set  RO  =  0 

SMX 

RO 

Clear  Interrupt  Mask 

CLIR 

CLEAR  ANY  PENDING  INTERRUPTS. 

TAH 

Stop  Timer  A  and  B  and  Reset  them 

TBH 

Both  to  Zero 

OTA 

RO 

0TB 

RO 

L 

R 1 , IVEC7 

; SET  UP  INTERRUPT  VECTORS  FOR  TIMER  A 

ST 

R 1 , 0002F 

;02F  is  Int  Svc  Ptr  Addr  for  Int  7 

L 

R 1  ,  IVEC9 

;  SET  UP  INTERRUPT  VECTORS  FOR  TIMERB 

ST 

R 1  ,00033 

;  033  is  Int  Svc  Ptr  Addr  for  Int  9 

RCFR 

RO 

CLEAR  THE  FAULT  REGISTER 

CLIR 

Clear  Pending  Interrupts 

ENBL 

Enable  Interrupts  Any  NEW  ONES 

LIM 

RO , 05940 

Reset  the  interrupt  mask 

SMK 

RO 

POPM 

RO  ,R1 

Restore  RO  and  R1 

URS 

R 1  5 

END 

Returning  the  Interrupt  Count  and  Timer  Register  Contents 

The  assembly  language  routine  GET_TIMERS  is  called  from 
the  procedure  GET_ALL_TIMES  in  package  TI ME_PACKAGE_ 1 7 50 A  and 
passes  two  long_integer  (32-bit)  objects  as  arguments.  When 
the  GET_TIMERS  routine  is  entered,  registers  3  and  4  contain 
the  addresses  of  the  two  values  that  the  GET_ALL_TIMES 
procedure  is  expecting  back.  GET_TIMERS  retrieves  the 
interrupt  count  for  interrupt  7/9  from  memory  location  500/501 
and  stores  this  in  the  lower  half  of  the  32  bit  return 
variable.  This  has  the  same  effect  as  multiplying  the 
interrupt  count  by  65,536.  GET_TIMERS  then  uses  a 


MIL-STD- 1750A  XIO  instruction  to  retrieve  the  values  of  the 
timer  registers  and  stores  these  values  in  the  upper  half  of 
the  return  variables  indicated  by  the  addresses  in  registers  3 
and  4  . 

Registers  3  and  4  were  used  in  the  assembly  routine  after 
the  TIME_PACKAGE_ 1750A  was  initially  compiled  and  I  found  that 
registers  3  and  4  were  being  used  by  the  Ada  procedure  to  pass 
the  return  addresses  of  the  output  parameters  to  the  assembly 
routine.  When  writing  assembly  language  routines  that  will  be 
called  from  Ada,  one  must  first  determine  the  registers  the  Ada 
calling  routine  is  using  to  pass  parameters  to  the  called 
assembly  language  routine.  GET_TIMERS  is  linked  to  an  Ada 
procedure,  also  called  GET_TIMERS,  using  the  pragma  interface. 

The  assembly  language  source  code  for  GET_TIMERS  is  given 
below. 


GET  TIMERS  Source  Code 

«*«*«***«***«*•«*««***•«*«««*•»««««*«««***«««««««***««««««««** 

«  Name:  GET_TIMERS 

*  Author:  Capt  Dan  Joyce 

*  Date :  31  Aug  87 

*  Vers  ion:  1.2 

»  Description:  This  is  a  1750A  assembly  language  routine 

*  designed  to  return  the  values  of  the  timer  A  and  Timer  B 

«  clocks  to  a  predefined  location  in  memory.  This  routine 

»  must  be  used  with  the  TI ME_PACKAGE .  The  timers  will  be 

*  loaded  in  memory  locations  identified  in  register  3  and  4: 

*  TlmerA  =>  [R3.R3+1] 

*  TimerB  =>  [R4.R4+1] 

*  The  value  of  the  timer  is  loaded  at  the  upper  half  of  the 

*  double  word  (higher  memory)  The  lower  half  will  contain 

»  the  number  of  interrupts  that  have  occurred,  so  the  entire 

*  32  bit  word  will  contain  the  total  number  of  ticks.  For 

*  example,  assume  that  3  interrupts  have  taken  place  on 

*  timer  A,  and  the  current  value  of  the  timer  A  register  is 


*  25  (hex).  The  value  for  [R3.R3+1]  will  be  (in  hex) 

*  00030025. 

*  The  number  of  interrupts  will  be  updated  by  modified 

*  Interrupt  service  routines  for  interrupt  7  (Timer  A)  and 

*  interrupt  9  (Timer  B)  in  the  assembly  routine  RESETIV, 

»  which  is  tied  to  the  Ada  procedure 

*  RESET_INT_VECT0RS_7_AND_9  with  a  pragma  interface  in 

*  TIME_PACKAQE_ 1750A .  The  number  of  interrupts  must  be 

*  stored  at  location  500  (timer  A)  and  501  (hex)  for  Timer 

*  B.  See  the  Source  for  RESETIV. ASM. 

* 

*  This  must  be  called  using  pragma  interface: 

* 

*  Ada  equivalent:  procedure  get_timers ( timer_a_ret , 

*  timer_b_ret) ; 

* 


MODULE 

GET 

EXPORT 

GET 

R0 

EQU 

0 

R  1 

EQU 

1 

R2 

EQU 

2 

R3 

EQU 

3 

R4 

EQU 

4 

R 1  2 

EQU 

12 

R 1  4 

EQU 

14 

R 1  5 

EQU 

15 

» 

GET_ 

TIMERS 

DSBL 

EQU  » 

PSHM 

R0 , R 1 4 

XORR 

RO  ,  R0 

L 

R2 , 0500 

STBX 

R 1  2  ,  R3 

L 

R2 ,0501 

STBX 

R 1  2 , R4 

AIM 

R3  ,  1 

AIM 

R4  ,  1 

ITA 

R2 

STBX 

R 1 2  ,  R3 

ITB 

R2 

Disable  interrupts  so  clock 
Can’t  wrap  around  during 
routine 

Save  Registers  R0,R1 
Clear  R0 


Load  *  Timer  A 
Store  contents 
[ R3+0 ]  (R12-12 

Load  *  Timer  B 
Store  contents 
[ R4  +  0]  ( R 1 2  - 


i ntpts 
of  R2  at 
=  R0) 

intpts 
of  R2  at 
12  =  R0) 


Add  1  to  Reg  3  and  R4  so  they 
point  to  the  next  locations 
in  memory  (second  16  bits) 

R2  <-  Timer  A 
Store  contents  of  R2  at 
[ R3  ♦  0  ]  ( R 1 2 


-  12  =  R0) 


;  R2  <-  Timer  B 
1  1  1 


STBX 


R12 ,R4 


P0PM 

R0 , R14 

ENBL 

URS 

R 1  5 

END 

;  Store  contents  of  R2  at 
;  [ R4  +  RO]  ( R 1 2  -  12  =  RO) 

{Restore  Registers  RO  to  R14 
;  Allow  Interrupts  again 
;  return 


Packaging  the  Procedures  for  Use 

T I ME_PACKAGE_1 750 A ,  finally,  groups  all  of  these 
procedures  in  one  place  and  defines  an  interface  through  the 
entirely  Ada  procedure  GET_ALL_T I MES ,  which  converts  the 
integral  values  of  Timer  A  and  B  'ticks'  to  a  floating  point 
value  in  seconds.  Floating  point  was  used  instead  of  fixed 
point  because  the  possibility  of  losing  precision  is  greater 
with  fixed  point  numbers,  even  using  deltas  of  0.00001  and 
0.0001.  The  comments  in  the  source  code  explain  how  to  use  the 
package . 


TIME  PACKAGE  1750A  Source  Code 


--  T I ME_PACKAGE_ 1 750 A 

--  This  package  contains  functions  and  procedures  that  will 
--  return  elapsed  time  to  the  caller. 


--  INSTRUCTIONS  FOR  USING  THIS  PACKAGE: 

1)  'With'  the  package  (and  ’use'  the  package  if  you 
--  don't  want  to  make  qualified  calls) . 

2)  Declare  at  least  two  objects  of  type  TIME_1750A 

--  (defined  in  this  package)  as  the  parameters  returned  by  the 
--  procedure  GET_ALL_TIMES ,  eg. 

timera_return  :  TIME_1750A  :=  0.0; 
timerb_return  :  TIME_1750A  :=  0.0; 

3)  Make  a  call  to  RESET_INT_VECT0RS_7_AND_9 .  This  should 
--  be  the  first  executable  statement  in  the  program  using  this 


--  package.  RESET_INT_VECT0RS_7_AND_9  allows 

--  TIME_PACKAGE_ 1750A  to  calculate  the  elaspsed  time. 

4)  Make  calls  to  GET_ALL_TIMES ,  eg: 

GET_ALL_TIMES ( timera_return , timerb_return) ; 

--  Author:  Capt  Dan  Joyce 

--  Date:  06  Sep  1987 

- -  Version :  1.6 


with  SYSTEM; 

package  TIME_PACKAGE_1750A  is 


subtype  time_1750A  is  L0NG_FL0AT  range  0.0  ..  1.0E30; 

current_total_aticks  :  long_integer  :=  0; 
current_total,bticks  :  long_integer  :=  0; 


--  These  two  memory  locations  are  used  by  the  interrupt 
--  Service  routines  as  storage  for  the  interrupt  count 
--  Get_Timers  will  read  the  number  of  timer  a/b  interrupts 
--  from  these  locations.  The  Address  Clause  keeps  Ada  from 
--  using  these  locations  for  anything  else. 


timera_interrupt_count  :  integer  :=  0; 

t imerb_lnterrupt_count  :  integer  :=  0; 

for  timera_interrupt_eount  use  at  16*0500*; 
for  t imerb_interrupt_count  use  at  16*0501#; 

procedure  RESET, INT_VECT0RS_7_AND_9 ; 

pragma  interface (assembly, reset_int_vectors_7_and_9 , 

’ resetiv ' ) ; 

procedure  GET_TIMERS ( at i cks_re tur n  :  out  long_integer ; 

bticks_return  :  out  long_integer )  ; 
pragma  interface (assembly,get_timers , 'get_timers’) ; 

procedure  GET_ALL_TIMES (  elapsed_timera  :  out  time_1750A; 

elapsed_timerb  :  out  tlme_1750A); 

end  T I ME_PACKAGE_ 1750 A; 

package  body  TIME, PACKAGE, 17 50 A  is 


procedure  GET_ALL_TIMES  (  e 1 apsed_t imera  :  out  time_1750A; 

e lapsed, timerb  :  out  time_1750A)  is 

begin 

GET_TIMERS (current_total_ati cks , 
current_total_bticks) ; 
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if  current_total_aticks  <  0  then 
current_total_aticks  :=  0; 
end  i f ; 


if  current_total_bticks  <  0  then 
current_total_bticks  :=  0; 
end  i f ; 


e 1 apsed_t imera  := 

TIME  1750A(  current  total  aticks)  /  100  000.0; 


elapsed_timerb  := 

TIME_1750A(  current_total_bticks)  /  10_000.0; 


end  QET_ALL_TIMES ; 


end  T I ME _ PACK AGE _ 1750A ; 


end i x  G ;  Two-Sample  t  Teat  Calculations 
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This  appendix  contains  the  two-sample  t  test  calculations 
used  to  test  the  hypothesis  that  the  mean  interrupt  delay  time 
for  I NT_TEST 1  was  less  than  that  for  I NT_TEST2 ,  INT_TEST3 ,  or 
INT_TEST4;  and  the  hypothesis  that  the  mean  interrupt  delay  for 
INT_TEST5  was  less  than  that  for  I NT_TEST6 . 

All  hypothesis  testing  was  done  at  the  0.01  level  of 
s i gn i f i cance .  The  sample  size  for  all  tests  was  100,  thus  the 
critical  value  for  the  one-sided  test  was 


'0.01,198 


2.33  (Larsen  and  Marx,  1986:580). 


The  formula  for  the  test  statistic  for  the  two  sample  t 
test  is : 

t  =  (  x  -  y  )  /  [  s  (  1/n  ♦  1/m) *  ]  (1) 

xy  P 

where 

s  =  pooled  variance, 

P 

n  =  sample  size  of  the  X  population, 

m  =  sample  size  of  the  Y  population. 

The  subscript  on  variables  in  this  appendix  refers  to  the 

interrupt  benchmark  number,  i.e.  x 2  is  the  mean  for  INT_TEST2 

and  s  is  the  pooled  variance  for  INT  TEST1  and  INT  TEST2. 
pi  2  ~ 

The  following  pooled  variances  were  calculated  from  the  sample 


variances  reported  in  the  benchmarks: 


7.234  *  10 


6.721  «  10 


7.567  »  10 


e  __  =  7.009  *  10 


The  following  sets  of  hypotheses  were  tested: 


Ho  1  2  ’ 

M1 

>_ 

V2 

vs  . 

Ha  1  2  : 

K1 

<  ^  2 

Ho13: 

U 

1 

)_ 

H  3 

vs  . 

Ha  1  3  : 

1 

<  H3 

H 

o  1  4 

'  1 

>_ 

u 

4 

vs  . 

Ha  1  4  : 

H1 

<  ^4 

H 

o5o 

H 

5 

>_ 

u 

6 

vs  . 

Ha56  : 

H5 

<  y6 

Using  formula 

1 

for  the 

test 

statistic 

and  the  sample 

means  reported 

i n  Tab 1 e  IV  in 

Chapter  5 , 

the 

foil owing  test 

statistics  were 

ca 1 cul a t ed  : 

£12  =  -35 

.  776 

£14 

=  -56. 

918 

£ 1 3  -  '55 

.4  14 

£  56 

=  -19. 

168 

In  all  cases,  these  values  are  less  than  -2.33,  the  critical  t 
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